I think this one should be discussed in its own thread:


What argument can be against getting diagnostic messages (e.g.
warnings) for non-explicit initialisation of all POD types in all
situations, being adopted in the C++ standard, when there is no
explicit initialisation provided by the programmer?


Also consider the recommendation of one programmer who in another
thread suggested the following type of explicit non-initialisation,
when we do not want explicit initialisation:


int x= void; // Explicit non-initialisation. No implementation diagnostics here.



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

[ 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                      ]

On Apr 18, 10:17 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
> I think this one should be discussed in its own thread:
>
> What argument can be against getting diagnostic messages (e.g.
> warnings) for non-explicit initialisation of all POD types in all
> situations, being adopted in the C++ standard, when there is no
> explicit initialisation provided by the programmer?

Existing code would be completely swamped in warnings. Build systems
would have to be changed to add suppression switches. An incredible
amount of noise would result in an incredible number of software
builds. The cost of upgrading from C++03 to C++0x would be multiplied
by the need to change build systems and/or code.

Sebastian


--
[ 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                      ]

In article
<aedc20b6-59b4-425c-82c8-7e3a850f8198@v19g2000yqn.googlegroups.com>,
  wasti.redl@gmx.net wrote:

> On Apr 18, 10:17 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
> > I think this one should be discussed in its own thread:
> >
> > What argument can be against getting diagnostic messages (e.g.
> > warnings) for non-explicit initialisation of all POD types in all
> > situations, being adopted in the C++ standard, when there is no
> > explicit initialisation provided by the programmer?
>
> Existing code would be completely swamped in warnings. Build systems
> would have to be changed to add suppression switches. An incredible
> amount of noise would result in an incredible number of software
> builds. The cost of upgrading from C++03 to C++0x would be multiplied
> by the need to change build systems and/or code.
>
> Sebastian

A decent compiler would allow the specific warning to be turned off,
thus providing a migration path to address the initialization issues.

Without knowing the C legacy, it's not obvious why "x" and "y" are
treated differently in the simplistic example below:

     #include <iostream>

     struct my_int
     {
         my_int(int data = 0) : data_(data) {}
         operator int() { return data_; }

     private:
         int data_;
     };

     int main()
     {
         int x;
         my_int y;

         std::cout << x+y << std::endl;
     }

it's even less obvious if the user of my_int can't see it's
implementation.

Jon

--
[ 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                      ]

Jonathan Jones wrote:
> In article
> <aedc20b6-59b4-425c-82c8-7e3a850f8198@v19g2000yqn.googlegroups.com>,
>   wasti.redl@gmx.net wrote:
>
>> On Apr 18, 10:17 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
>>> I think this one should be discussed in its own thread:
>>>
>>> What argument can be against getting diagnostic messages (e.g.
>>> warnings) for non-explicit initialisation of all POD types in all
>>> situations, being adopted in the C++ standard, when there is no
>>> explicit initialisation provided by the programmer?
>> Existing code would be completely swamped in warnings. Build systems
>> would have to be changed to add suppression switches. An incredible
>> amount of noise would result in an incredible number of software
>> builds. The cost of upgrading from C++03 to C++0x would be multiplied
>> by the need to change build systems and/or code.
>>
>> Sebastian
>
> A decent compiler would allow the specific warning to be turned off,
> thus providing a migration path to address the initialization issues.

Which will not help anyone whose contract specifies that the object code
must be produced with a standard conforming compiler.

--
[ 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                      ]

On Apr 18, 1:17 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
> I think this one should be discussed in its own thread:
>
> What argument can be against getting diagnostic messages (e.g.
> warnings) for non-explicit initialisation of all POD types in all
> situations, being adopted in the C++ standard, when there is no
> explicit initialisation provided by the programmer?
>
> Also consider the recommendation of one programmer who in another
> thread suggested the following type of explicit non-initialisation,
> when we do not want explicit initialisation:
>
> int x= void; // Explicit non-initialisation. No implementation diagnostics here.

My personal point of view is, "no" to first idea, "yes" to second one.
The reason why requiring diagnostic is a bad idea has already been
explained at length: it will suddenly make the compiler balk at tons
of existing code by default, on any conformant implementation. This is
too high a price.

On the other hand, the adoption of an explicit way to say "this is not
initialized", such as the "= void" syntax, would allow the compilers
to provide an "uninitialized POD" warning with opt-in model, and with
a standard way to work around any such thing (this last bit is
important!). I would expect that, if such a thing is introduced, it
would quickly become good practice, so the transition would happen
anyway, but at a much slower pace (which is good) - and then maybe by C
++2x non-initialized PODs could officially be deprecated :)


--
[ 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                      ]