Re: About adoption of implicit zero initialisation of POD types in
the C++ standard
Organization: http://groups.google.com
References: <grksmd$2koe$3@ulysses.noc.ntua.gr>
<96f2770d-281b-461f-b72c-3ee79c3558de@y6g2000prf.googlegroups.com>
<bYednWEn4bvJY3vUnZ2dnUVZ8j-dnZ2d@bt.com>
<4a8d057f-94db-4a0a-a2eb-c69acea0d318@w35g2000prg.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Clcppm-Sequence: 23488
X-Original-Date: Fri, 17 Apr 2009 06:14:47 -0700 (PDT)
X-Submission-Address: c++-submit@netlab.cs.rpi.edu
On 16 Apr, 23:50, Pavel Minaev <int...@gmail.com> wrote:
void show_value(std::shared_ptr<int const> ptr){std::cout << *ptr;}
// note the assumption that code makes
int main() {
std::shared_ptr<int> i_ptr;
foo(i_ptr);
}
This is something that can be written in C++0x, or, for that matter,
in C++03 with TR1 today, with i_ptr being implicitly initialized to a
null pointer. For any arguments along the lines of "I do not want the
compiler to correct my code silently", they would also have to explain
why a smart pointer in this case should be treated any differently
from a raw pointer.
It would seem that the defect is not providing a mechanism to allow
the programmer to inform the compiler that a user-defined type is in
an uninitialized state. Adding automatic initialization would make the
defect apply to built in types too.
-Ed
--
(You can't go wrong with psycho-rats.)(http://mi.eng.cam.ac.uk/~er258)
/d{def}def/f{/Times s selectfont}d/s{11}d/r{roll}d f 2/m{moveto}d -1
r 230 350 m 0 1 179{ 1 index show 88 rotate 4 mul 0 rmoveto}for/s 12
d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]