RE: [boost] #pragma once again

From: Ferdinand Prantl (ferdinand.prantl_at_[hidden])
Date: 2003-09-10 07:30:09

Hello Dan,

hmmm, your evaluation looks interesting (at least for me...) - from
one-third one-half reduction is relly worth it, if id does not cost
non-readable code. To have the code multiplatform, I would enclose the
pragma in the ifdef/endif pair. Did you do mean something like this does the
thing?

----------------------------------------------bof
#ifdef _MSC_VER
#pragma once
#endif

#ifndef XXX_H
#define XXX_H
...
#endif // XXX_H
----------------------------------------------eof

I am thinking about some nifty script inserting this into every
boost/non-boost header in my project and trying to recompile it to see the
difference... ;-)

Best Regards,
Ferda

> -----Original Message-----
> From: Dan Muller [mailto:q266e1d02_at_[hidden]] 
> Sent: Tuesday, September 09, 2003 17:43
> To: boost_at_[hidden]
> Subject: [boost] #pragma once again
> 
> 
> 
> I know that the "#pragma once" issue has been debated on this list in 
> the past, but I would like to bring it up again because of 
> problems I'm 
> having with a project at work.
> 
> Our application is a large bookkeeping program with various internal 
> layers to isolate the database handling from the user interface, and 
> with a non-trivial proprietary UI framework that binds the database 
> layers to MFC code. We're using VC7.1 and boost 1.30.0. One of the 
> database layers defines a number of classes to represent the 
> contents of 
> database fields. I recently modified some of these classes to 
> use boost 
> code. (Specifically, I'm making use of the date and date-time 
> libraries, 
> but that's not particularly relevant.)
> 
> Our builds have slowed down a lot, and it took me a while to 
> determine 
> why. I wrote some Perl scripts that would run our .cpp files 
> through the 
> preprocessor and analyze the resulting #line directives. (A very slow 
> way to do this, but very accurate.)
> 
> I analyzed one project carefully, the one that defines the UI 
> framework. 
> It also makes heavy use of the database layer's generic parts. It was 
> indirectly including boost\config.hpp 6.931 times per .cpp 
> file in the 
> project -- all due to indirect use of boost through the database 
> subsystem. There are even pieces of the mpl included, even though we 
> don't directly use it in our own code. (boost\mpl\aux_\config 
> \overload_resolution.hpp, 0.99 times per .cpp file.)
> 
> One of our developers tried gathering all of the boost 
> includes from the 
> database layer into one header file, to which he also added a "pragma 
> once". He replaced all boost-related includes with a 
> reference to this 
> file. Finally, he included this file in the UI-level project's 
> precompiled headers. Build time was reduced by half. Similar 
> reductions 
> (one-third to one-half) have been noted in other projects affected by 
> this. I'm not particularly happy with this solution from a 
> maintenance 
> perspective, though.
> 
> Now, obviously, there are a couple of things going on here. 
> Precompiling 
> helps a lot. But unless very strict discipline is used in adding 
> inclusions, the precompiled header mechanism won't prevent multiple 
> inclusions of files. Although include guards help, they don't help 
> enough -- the sheer time involved in looking a file up and reading it 
> hurts, as Lakos has demonstrated. There have been previous 
> discussions 
> on this list that talked about other shortcomings with the 
> include garud 
> idiom, related to choosing the preprocessor symbol to use. So 
> even if a 
> compiler, like gcc, recognizes the idiom and gives it special 
> handling, 
> there are still shortcoming to this tradition.
> 
> It would be really helpful to those of us working with VC if boost 
> developers were encouraged to use #pragma once, suitably guarded. I 
> would think that a global boost configuration setting, defaulted 
> appropriately per compiler, could be used to guard it.
> 
> Thanks for listening...
> 
> -- 
> Dan Muller
> "So that's what an invisible barrier looks like!" (Time Bandits)
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>