From 5761961513547218795 X-Google-Thread: 7894ca11fe,8390690191732735 X-Google-Attributes: gid7894ca11fe,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 30 Dec 2009 14:50:08 -0600 Return-Path: To: (Usenet) From: James Kanze Newsgroups: comp.std.c++ Subject: Re: Why is std::array an aggregate? Organization: http://groups.google.com Sender: cppmods@cs.rpi.edu Approved: james.dennett@gmail.com Message-ID: References: <2fba9f88-3e5e-472f-a2fa-b7b415f07f69@g26g2000yqe.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 X-Original-Date: Tue, 29 Dec 2009 09:40:02 -0800 (PST) X-Submission-Address: std-c++@netlab.cs.rpi.edu Date: Wed, 30 Dec 2009 14:41:16 CST Lines: 95 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-7xumqQLJBdNx8mdlbA6VXHzCIFY/9ec3r8SUb7LwuV5jCm6cbblHGUNia4zFRc7HDrruLTy5ptKljb2!SayEzRTuPEvXZt77KZHZCRIJxemsboZ3sYXXAx6tvI7p2uWmvINPbBACB5y0wZ/dEpYuEFFGGB7g!WkgIewUiqjhkm90NT1oWCQ513SM= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: g2news1.google.com comp.std.c++:1973 On 21 Dec, 04:02, Scott Meyers wrote: > James Kanze wrote: > > That still means you have to write the size. An exception > > isn't as good as a compiler error, and a compiler error > > isn't as good as not having to write the size to begin with. > Perhaps, but I don't see your point, because you have to > manually specify the size of a std::array if you initialize it > with a brace initializer list, regardless. That's exactly my point. It still only does half the job; with a C style array, I don't have to specify the size. > > What's special is that it can also be initialized > > statically: > > std::array< int, 3 > a = { 1, 2, 3 }; > > Regardless of where this definition appears, I'm guaranteed > > that it occurs before *any* user defined code, including > > code in constructors of other static objects. In certain > > cases, that's a useful guarantee. > Is this really true? What about the following at namespace > scope? > std::array a = { f(), g(), h() }; > std::array b = { 1, 2, 3 }; It's really true that std::array can be initialized statically. Of course, if you don't provide static initializers, it won't be, but that's the case for a C style array as well. > Here's what draft C++0x has to say in 3.6.2/2, which I believe > is where we need to look: > > Objects with static storage duration (3.7.1) or thread > > storage duration (3.7.2) shall be zero-initialized (8.5) > > before any other initialization takes place. > > Constant initialization is performed: > > - if each full-expression (including implicit conversions) > > that appears in the initializer of a reference with static > > or thread storage duration is a constant expression (5.19) > > and the reference is bound to an lvalue designating an > > object with static storage duration or to a temporary (see > > 12.2) > > - if an object with static or thread storage duration is > > initialized such that the initialization satisfies the > > requirements for the object being declared with constexpr > > (7.1.5). > > > Together, zero-initialization and constant initialization > > are called static initialization; all other initialization > > is dynamic initialization. > In the code I showed, b isn't a reference, so the first bullet > doesn't apply. b isn't declared constexpr either, so it's not > clear to me that the second bullet applies, either, although > the wording is rather odd. I'm not too clear on all of the latest changes in the standard either. As specified and implemented in the Boost library, the intent was clearly that static initialization could be used, and it certainly fulfills the rules for static initialization according to the definition in the current standard. But I really doubt that the intent of the second bullet is to restrict static initialization to objects actually declared constexpr; that would break an enormous amount of code. > If "the object" were changed to "an object," I'd probably > conclude that b can be statically initialized. With the > current wording, "the object" pretty clearly refers to the > object being initialized, so as things stand now, I don't > think that b can be statically initialized. If not, a would > be initialized before b, and in that case, arbitrary user code > would be executed before b were defined. I'm not sure I follow your reasoning. As I read it, the wording doesn't say that the object must be declared constexpr; it says that it must meet the requirements for constexpr, i.e. that declaring it constexpr would be legal. -- James Kanze -- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]