- C++ Middleware Writer - 1 Update
- Arrays of strings - 2 Updates
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 19 11:55PM +0100 On 19/05/2016 22:43, David Brown wrote: > So it is a reasonable rational assumption that Genesis is fictional - > but it is not /proven/ to be. However, the onus is on believers to > provide evidence that the book is non-fiction. Utter bullshit mate. Evolution is BOTH fact and theory. As evolution is a fact we know humans evolved but according to Genesis Adam had no parents so yes evolution being a fact does prove that Genesis is a fiction. /Flibble |
Paul <pepstein5@gmail.com>: May 19 03:01PM -0700 I think that std::string array[4]; defines array as an array of 4 empty strings. However, I can't justify this assertion (other than by experimenting). For example, int intArray[4]; does not result in an array of four zeroes even though int() evaluates as 0. So the fact that the std::string default constructor results in an empty string doesn't tell me what happens in the case of an array. Could anyone enlighten me? Thanks, Paul |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 20 12:51AM +0200 On 20.05.2016 00:01, Paul wrote: > fact that the std::string default constructor results in an empty > string doesn't tell me what happens in the case of an array. > Could anyone enlighten me? `int` is a built-in type, which is an example of a Plain Old Data type like in C, which has no specified default initialization. So, assuming your array is a local variable, with default initialization nothing happens. • C++11 §8.5/11: If no initializer is specified for an object, the object is default- initialized; ; if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value. • C++11 §8.5/6: To default-initialize an object of type T means: — if T is a (possibly cv-qualified) class type (Clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor); — if T is an array type, each element is default-initialized; — otherwise, no initialization is performed. So, by the second dash of §8.5/6, each element of the `int` array is default-initialized, and by the third dash, since `int` is neither class type nor an array, no initialization is performed. And then by §8.5/11 again (now applied to array item) that leaves each item with an indeterminate value. `std::string` is a class type with a default constructor. Default initialization for an object of this type uses the default constructor, which gives you an empty string. This is the first dash of §8.5/6. × × × Things are different if the array is at namespace scope, because namespace scope variables are zero-initialized before anything else. × × × For a local variable you can get zero initialization by specifying value initialization, which reduces to call to default constructor or zero initialization depending on the type. E.g. like this: int ai[4] = {}; // Very zero'ish. Alternatively you can use a `std::vector` instead of a raw array: vector<int> vi( 4 ); // Also very zero'ish. This relies on the `std::vector` constructor to zero things. In contrast, for historical reasons (as `boost::array` for C++03) the `std::array` class has no defined constructor, and doesn't zero things unless you give an initializer. And so array<int, 4> argh; // Very indeterminate. … just gives indeterminate values. :( One might argue that this proves that the Boost route into standardization is problematic. While something is proven as part of Boost, the language evolves (with C++11 supporting list-initialization), changing the context, so that the Boost thing is now much less than an optimal solution. It's a proven design, but only for the previous incarnation of the language; the world is imprefect! Cheers & hth., - Alf |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment