Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: Linkage of static members Message-ID: Date: 2 Jul 90 21:59:48 GMT References: <10460@batcomputer.tn.cornell.edu> <274@taumet.com><31208@cup.portal.com> <31285@cup.portal.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 54 In-reply-to: wmmiller@cup.portal.com's message of 30 Jun 90 17:02:18 GMT In article <31285@cup.portal.com> wmmiller@cup.portal.com (William Michael Miller) writes: pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > Ahh, but consts have internal linkage unless _explicitly_ specified > extern. Which rule prevails? There's no conflict. The rule to which you refer states: "A name of file scope that is explicitly declared const and not explicitly declared extern is local to its file" (ARM 3.3). Const class members do not have file scope. But static class members are *defined* at file scope, as you say: (Rereading these two comments back-to-back make it evident that the terminology in the ARM needs to be tightened up: const class members don't have file scope because they're declared inside a class; however, static class members *must* be defined at file scope. Perhaps concepts like "introducing declaration" and "defining declaration" should be used.) I am starting to think that the 3.0 ARM will be in several volumes, and will be sold by door-to-door salesmen, and that soon Harvard will open a Language Law school, and all that :-). You seem to find a lot of problems that don't particularly seem like problems to me. C++ is clearly not the most elegant, concise, and formally pure language conceivable, but I don't think it's as fundamentally flawed as you do. I do not think it is fundamentally flawed; I think it does mostly the right things for all the wrong reasons, and in a terribly haphazard way. I seem to understand that C++ is being developed with a "let's try this feature" approach, which may very well be pragmatic, but has some undesirable consequences. Eiffel (which I do not like) at least has a _seemingly consistent_ language and software design philossophy behind (and then some incredible slips like references!). Maybe it is the problems of success; for an example of a detail it is arguable that 'this' (which should not exist, however) should be a reference and not a pointer, but it's too late to change that. I was recently rereading Stroustrup's paper on MI in the Usenix journal. He has an appendix rejecting one flavour of delegation, an extremely elegant and C-ish technique, because users were confused by it. Instead of thinking that maybe the proposed flavour of delegation was wrong, he throws away delegation entirely, and bang! we get several dozen pages and untold complications about the sordid consequences of Simula67 style prefixing extended to multiple prefixing. I wonder how confused are users now... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk