Boost logo

Boost :

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

#ifdef _MSC_VER
#pragma once

#ifndef XXX_H
#define XXX_H
#endif // XXX_H

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,

> -----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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at