From -6746021460712294731 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,307cbe6f0ea2ccd3 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-06-11 12:09:57 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: maciej@maciejsobczak.com (Maciej Sobczak) Newsgroups: comp.std.c++ Subject: Re: Recommendation to the Standards Committee Date: Wed, 11 Jun 2003 19:09:53 +0000 (UTC) Organization: http://news.icm.edu.pl/ Lines: 34 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <_ULEa.10852$KF1.271850@amstwist00> <3EE50908.9060202@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1055358593 28592 10.0.0.1 (11 Jun 2003 19:09:53 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 11 Jun 2003 19:09:53 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 19QAym-0007R1-00 for mail2news@news.news.demon.net; Wed, 11 Jun 2003 19:09:52 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA15917; Thu, 12 Jun 2003 05:09:49 +1000 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Tue, 10 Jun 2003 09:00:34 +0000 (UTC) X-Accept-Language: en-us, en X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Spam-Status: No, hits=-9.1 required=5.0 tests=INVALID_MSGID,IN_REP_TO,NOSPAM_INC,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_03_05,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Xref: archiver1.google.com comp.std.c++:19685 Hi, The problem with this proposal is also that Standard does not even guarantee that headers are physical files. The #include <...> directive may just "swich on" the appropriate definitions, without reading any file. It is also worth noting that modern compilers use the idiom described by Lakos by themselves, I mean - you do not need to guard the #include <...> directive with additional (external) #ifdefs. If the header contains the internal guards (which do not need to be standardized), the preprocessor regognizes them (everything in the header is inside the internal guards) and if there is later #include with the same header name, the file is simply not read, because the preprocessor already knows there are internal guards that would make the inclusion futile. With this in mind, there is probably no need at all to standardize internal guards - just make this a Quality of Implementation issue for compiler vendors. If some compiler does not have this feature, you will just have to wait for the needless file scans (this may be a problem in network environments, I know). But we gain implementation freedom at the same time without putting too much stuff into the already thick Standard. -- Maciej Sobczak http://www.maciejsobczak.com/ Distributed programming lib for C, C++, Python & Tcl: http://www.maciejsobczak.com/prog/yami/ --- [ 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.jamesd.demon.co.uk/csc/faq.html ]