Re: C++0x - a quick and dirty introduction (as of November 2007)
Gabriel Dos Reis wrote:
On Tue, 18 Dec 2007, Walter Bright wrote:
| Gabriel Dos Reis wrote:
| > On Mon, 17 Dec 2007, Walter Bright wrote:
| >
| > | The D programming language solves the problem from the opposite direction
| > | than
| > | C++ does. It is always determinable, from the context, whether foo()
| > | should be
| > | evaluated at compile time or run time. For example,
| > | static int x = foo();
| > | is always evaluated at compile time, since dynamic initializers for static
| > | variables are not allowed (such belong in the static constructor).
| >
| > Yes, a `solution' to the problem can be `just ban'.
| > However, banning dynamic initializers for static variables isn't a
| > viable option in the context of C++ now.
|
| I understand, but at some point, I think C++ will seriously have to look at
| obsolete features and consider them for removal in order to allow the language
| to modernize.
Why do you consider dynamic initialization of global or static objects an
obsolete feature?
Because:
1) its shortcomings have produced the need for another storage class,
'constexpr', as discussed here.
2) I very much like to be able to look at initializations and see if
they will be done at compile time or runtime without having to poke
through (potentially voluminous) headers. One of the first design
decisions of the D programming language was to scrap dynamic
initializers for static data. Dynamic initializers go into clearly
marked static constructors, instead of being implied.
3) Dynamic initialization of local statics introduces multithreading
issues. This can be dealt with by the compiler always using a mutex,
which introduces bloat all over the place, or optional mutexes with a
compiler switch leading to bloat or overlooked bugs, or using a simple
static one-shot which suffers from race conditions that aren't at all
obvious from code inspection.
4) C++ leaves undefined the order of inter-module static construction,
which is simply unacceptable from a QA standpoint. Having the dynamic
construction collected together in a static constructor at least gives
the QA engineer an identifiable place to look for ordering problems.
5) Collecting the dynamic initializers into a static constructor enables
the intra-module order of construction to be controlled independently of
the definition order.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]