On Mon, 30 Dec 2002 11:18:41 +0100, Alberto Barbati <[EMAIL PROTECTED]> wrote:
>Gennaro Prota wrote: >> Hmm... frankly I haven't used it anymore. I'm under the impression >> they have fixed it now, but last time I checked it had a lot of bugs. >> It was easy, for instance, to end up including the same file twice if >> it was reached through different paths (e.g.: #include "subdir/file.h" >> in A.cpp and #include "file.h" in subdir/file2.h). Usually one doesn't >> notice the error, because he uses both the pragma and the canonical >> include guard, but that means of course that the speed gain comes to >> nothing. Probably it was VC++ 5.0 though. > >You are missing the point here. "#pragma once" is not really >"functional", in the sense that it's not (or should not be) used >*alone* to realize the "include me once" effect. I think you don't know yet how pedantic I'm as far as correctness and standard compliance is concerned. I would have never used the #pragma once 'alone', really! ;-) I did that just for experimenting, as I'm always sceptical about advertisements of the 'this is faster' or 'this is more efficient' kind, especially when the supposed advantage comes at the cost of portability. Thus, my intent was to verify if it was really "useful" in terms of speed, but I saw that it almost never worked when the header names (but not the included source file) were different. As I said, they have probably fixed it now, at least with VC++ 6.0 SP5, because in a few tests I did before posting I didn't see any error. As to the speed gain, I'll take your word for it. I was just saying that, when the pragma once doesn't work, it's simply useless. You may accept that, no problem. The important thing is to know that then the speed up is just illusion. That's all. >> [...] In effect, the whole story about file inclusion should be >> the other way round: any source file is included at most once for each >> TU, unless the programmer requires otherwise ;-) > >I agree, but we can't give the burden of avoiding multiple inclusions to >the "user". Realistically, with large projects such intent is hardly >achievable by anyone. To the language, not to the user. Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
