bs@alice.UucP (Bjarne Stroustrup) (04/08/86)
Nathan C. Myers (orstcs!nathan) writes > I have pencilled in all of bs's corrections from the second edition of the > book. Are there additional language specifications elsewhere? No. > With strong type-checking, there's little reason *not* to make globals > default to static. I would call it a feature. I tried that. It worked, but the pressure for C compatibility was immense (and not all just backward looking). One convincing argument is that since C and C++ will live side by side in many environments for years to come there should be no programs that is legal C and legal C++ but have different meanings. Defaulting to the scope of non-local variables to be the source file (C static) rather than the whole program (C extern) puts lots of innocent looking programs in this catagory. > I suspect Dr. Stroustrup is beginning to regret allowing statics in > classes, with all the worm-cans opening. No. Static members are useful as implemented and can be implemented in general without serious problems (allowing the initializer syntax for static members and ensuring that these initializers refer only to stuff that can be handled is no big deal). The snag is that class declarations tend to appear in header files and header files tend to be included in several compilations. A static member should be initialized exactly once. You need loader support to ensure that. As usual, a single loader can easily be improved to handle this, but you cannot fix every loader in the world so by removing the restriction you create a serious compatibility problem. - hence the restriction. Like C's 8 character limit for identifiers the no-initializers-for-statics restriction is a price we have to pay for portability. Most consts could be handled without encountering this problem. Personally I stick to things like pointers and integers a static members. Since they are default initialized to 0 I don't run into problems.