From -5545147768412320890 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,307cbe6f0ea2ccd3 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-06-11 11:04:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!newsfeed.vmunix.org!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: kanze@gabi-soft.fr Newsgroups: comp.std.c++ Subject: Re: Recommendation to the Standards Committee Date: Wed, 11 Jun 2003 18:04:22 +0000 (UTC) Organization: http://groups.google.com/ Lines: 61 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> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1055354662 28365 10.0.0.1 (11 Jun 2003 18:04:22 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 11 Jun 2003 18:04:22 +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 19Q9xN-0007NM-00 for mail2news@news.news.demon.net; Wed, 11 Jun 2003 18:04:21 +0000 X-Received: by mulga.cs.mu.OZ.AU id EAA09417; Thu, 12 Jun 2003 04:04:18 +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: 11 Jun 2003 14:34:50 GMT X-Spam-Status: No, hits=-6.0 required=5.0 tests=NOSPAM_INC,NO_REAL_NAME,QUOTED_EMAIL_TEXT,REFERENCES, SATISFACTION,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:19681 francis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:... > In article <3EE50908.9060202@hotmail.com>, Andrey Tarasevich > writes > >Yeah, but it looks like the main point of the method Brian is using > >is that the guarding '#ifndef'/'#endif' is placed _outside_ the > >header file. In this case the preprocessor doesn't even have to > >search for already included files, open them or try parsing them. The > >'#once' solution doesn't help in this case, since '#once' directive > >is supposed to be specified _inside_ header files. From this respect > >'#once' is not much different from the standard "internal > >'#ifndef'/'#define'/'#endif' approach". But it looks like Brian is > >not satisfied with the latter. Under this circumstances, I don't > >think he will be satisfied with any other "internal" solution. > But I do not understand the problem. Only the designer of a header > file can know if it should or should not be multiply included into a > TU. > Being able to write: > #once > at the start of a header file would solve the problem because > compilers would then read the file the first time, mark it as read in > its tables and not try to read it again. > Another solution would be to make header files default to single > inclusion per TU and provide a > #multiple > directive that over-ruled the default and required the compiler to > re-read the file each time it is included (sort of the pre-processor > equivalent of volatile). This would be nice if we were creating the language from scratch, but we have existing code to deal with. I doubt if any existing headers which expect to be included multiple times use #multiple. And of course, without the historical baggage, I daresay that we could come up with something better than #include entirely:-). Finally, as has been pointed out, a compiler doesn't need #once for this. Good compilers already note when an included file is protected by include guards, memorize the conditional, and when they see the same file about to be included, verify the conditional, and only open the file if it is false (and the contents would be read). -- James Kanze GABI Software mailto:kanze@gabi-soft.fr Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16 --- [ 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 ]