Menu
▾
▴
cpp-netlib-devel
|
From: Dean M. B. <mik...@gm...> - 2010-10-25 10:17:03
|
Hi Guys, So I'm on a meagerly-powered machine and I cannot buy a new one until I get a job (my wife insists :D) so I've made some steps to start reducing the compile-times of release 0.8. One of the first casualties in the compile-time reduction effort is the Boost.Concept_check stuff on the fundamental accessors/wrappers. Now there are still a lot of other things I can do to start reducing compile-times. One is incorporating precompiled headers into the build, and start pre-compiling almost every single header in the library. Has anyone played around with CMake and how to make precompiled headers part of the build process? I have seen some Google results on the matter but I currently have no time/patience to muck around with that. I'm nearing the completion of the asynchronous server that invokes request handlers in a thread pool and although the compile times have been reduced in the HTTP client side of things I would really appreciate some CMake kung-fu from people on the list to incorporate precompiled-headers (so that we can make that part of the install step in 0.8). Thanks in advance and I hope to hear your comments/feedback. The relevant change in 0.8-devel to remove the Boost.Concept_check stuff on the fundamental message accessors is here: http://goo.gl/orfM -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-10-25 14:32:33
|
> Dean Michael Berris wrote on Monday, October 25, 2010 > ... I've made some steps to start > reducing the compile-times of release 0.8. One of the first casualties > in the compile-time reduction effort is the Boost.Concept_check stuff > on the fundamental accessors/wrappers. > Just to throw it out there, maybe some of this could be controlled with a BOOST_CPP_NETLIB_COMPILE_FAST macro, enabling it to be optional. > Now there are still a lot of other things I can do to start reducing > compile-times. One is incorporating precompiled headers into the > build, and start pre-compiling almost every single header in the > library. Pre-compiled headers seem like they are going to be a mess, and conceptually similar to going to a non-header-only implementation. I like the idea of header-only, but maybe a more library-based one would help the compile time. > Has anyone played around with CMake and how to make precompiled > headers part of the build process? I have seen some Google results on > the matter but I currently have no time/patience to muck around with > that. > Nothing else in Boost requires CMake, as far as I know. Boost-devel has had some rumblings about a change, but right now Boost.Build is the Boost standard. > I'm nearing the completion of the asynchronous server that invokes > request handlers in a thread pool and although the compile times have > been reduced in the HTTP client side of things I would really > appreciate some CMake kung-fu from people on the list to incorporate > precompiled-headers (so that we can make that part of the install step > in 0.8). > Compile time *is* an important issue, but the beauty of a header library is that there is no install step- you just copy the files into your directory tree. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2010-10-26 04:22:43
|
On Mon, Oct 25, 2010 at 10:32 PM, Nelson, Erik - 2 <eri...@ba...> wrote: >> Dean Michael Berris wrote on Monday, October 25, 2010 >> ... I've made some steps to start >> reducing the compile-times of release 0.8. One of the first casualties >> in the compile-time reduction effort is the Boost.Concept_check stuff >> on the fundamental accessors/wrappers. >> > > Just to throw it out there, maybe some of this could be controlled with > a BOOST_CPP_NETLIB_COMPILE_FAST macro, enabling it to be optional. > Actually there's already a way to disable the concept checking parts with a Macro. My objection to yet another preprocessor macro is that the code gets pretty ugly -- look at the client switching for BOOST_NETWORK_ENABLE_HTTPS to see what I mean. The reason also that these concept checks are removed from the fundamental accessors is that because the concept checks are meant to be applied to algorithms. In my head the only algorithms that can be applied to messages at the moment are: 1. Rendering 2. Transformations 3. Adaptations Algorithms for Rendering are still embedded in the client implementations. I'm seeing a need for a render(...) algorithm that deals with concepts instead so that we can abstract out the rendering of messages based on their protocol/domain. I haven't removed the concepts, I just removed the concept checks on the fundamental accessors -- like source, destination, headers, and body -- because they tend to be recursive and introduce all kinds of header include ordering hell. :D >> Now there are still a lot of other things I can do to start reducing >> compile-times. One is incorporating precompiled headers into the >> build, and start pre-compiling almost every single header in the >> library. > > Pre-compiled headers seem like they are going to be a mess, and > conceptually similar to going to a non-header-only implementation. I > like the idea of header-only, but maybe a more library-based one would > help the compile time. > Well, not really. Let me explain why. First, the precompiled headers will only be built if the compiler supports it. This means for compilers that don't support precompiled headers, there's no effect. Second, the precompiled headers will be placed in the same directory as where the original header is placed. Third, this helps a lot in development mode. Having precompiled headers while developing a header-only library is a good way to cut down compile times immensely. Having precompiled headers around is not the same as building something and linking against it. The reason I didn't want to build external libraries is so that there's no ABI compatibility issues to take care of when doing releases. Precompiled headers don't impose this problem. >> Has anyone played around with CMake and how to make precompiled >> headers part of the build process? I have seen some Google results on >> the matter but I currently have no time/patience to muck around with >> that. >> > > Nothing else in Boost requires CMake, as far as I know. Boost-devel has > had some rumblings about a change, but right now Boost.Build is the > Boost standard. > Well there is a Boost mirror where everything is in CMake -- it's hosted on GitHub, maintained by the ryppl folks. The reason I'm using CMake for development is because it's just way faster to start building things compared to using bjam and Boost.Build. Having to wait 1 minute before anything gets compiled is not a good way of spending that time. ;) Of course at this time Boost.Build is still supported. I just like to use CMake locally for testing. >> I'm nearing the completion of the asynchronous server that invokes >> request handlers in a thread pool and although the compile times have >> been reduced in the HTTP client side of things I would really >> appreciate some CMake kung-fu from people on the list to incorporate >> precompiled-headers (so that we can make that part of the install step >> in 0.8). >> > > Compile time *is* an important issue, but the beauty of a header library > is that there is no install step- you just copy the files into your > directory tree. > Yeah, but... if you get the best of both worlds with precompiled headers -- you just copy them along with the files when you "install" -- then I don't see why trying precompiled headers would be a bad thing for a header-only library. Having precompiled headers is really going to be transparent to the users of the library, because if the compiler they're using supports them then there's an advantage. Otherwise, no disadvantage. Also, Boost has an "install" step which places the headers and all other built libraries into certain places. Integrating with the "install" step of Boost will have to be done in the Boost.Build files anyway. ;) Just sayin'... precompiled headers make sense for header-only libraries. :D -- Dean Michael Berris deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-10-25 18:59:15
|
Hi, On 25 October 2010 16:32, Nelson, Erik - 2 <eri...@ba...>wrote: > > Dean Michael Berris wrote on Monday, October 25, 2010 > > ... I've made some steps to start > > reducing the compile-times of release 0.8. One of the first casualties > > in the compile-time reduction effort is the Boost.Concept_check stuff > > on the fundamental accessors/wrappers. > > > > Just to throw it out there, maybe some of this could be controlled with > a BOOST_CPP_NETLIB_COMPILE_FAST macro, enabling it to be optional. > > Now there are still a lot of other things I can do to start reducing > > compile-times. One is incorporating precompiled headers into the > > build, and start pre-compiling almost every single header in the > > library. > > Pre-compiled headers seem like they are going to be a mess, and > conceptually similar to going to a non-header-only implementation. I > like the idea of header-only, but maybe a more library-based one would > help the compile time. > I agree with this point. IMO, although I agree that the header-only approach has merits, it seems that since we're already requiring that users link against Boost's system, regex and date_time libraries, we don't seem to be gaining much from this approach anyway. Including the compile time problem and making cpp-netlib strictly being header-only has very few benefits. I would suggest a better use of our focus should be on portability. Additionally, I have been doing a lot of development in embedded systems, where the long compile times and large binaries that are generated pretty much rules out using cpp-netlib. This is a shame, because this is an area where cpp-netlib can provide a lot of benefits to developers. > > > Has anyone played around with CMake and how to make precompiled > > headers part of the build process? I have seen some Google results on > > the matter but I currently have no time/patience to muck around with > > that. > > > > Nothing else in Boost requires CMake, as far as I know. Boost-devel has > had some rumblings about a change, but right now Boost.Build is the > Boost standard. > Sadly ;) > > > I'm nearing the completion of the asynchronous server that invokes > > request handlers in a thread pool and although the compile times have > > been reduced in the HTTP client side of things I would really > > appreciate some CMake kung-fu from people on the list to incorporate > > precompiled-headers (so that we can make that part of the install step > > in 0.8). > > > > Compile time *is* an important issue, but the beauty of a header library > is that there is no install step- you just copy the files into your > directory tree. > But there is an install step, because of the dependencies that cpp-netlib has - and will have: in developing the XMPP client I'll be linking to an XML parser library and TLS library. Other protocol implementations will bring other dependencies and we'll have to deal with those too. Regards, Glyn |
|
From: Glyn M. <gly...@gm...> - 2010-10-25 19:10:56
|
On 25 October 2010 20:59, Glyn Matthews <gly...@gm...> wrote: > Hi, > > <snip /> > Regards, > Glyn > > P.S. this is related to an issue that was created on Github: http://github.com/cpp-netlib/cpp-netlib/issues#issue/20 |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-10-25 19:21:07
|
>>Erik Nelson wrote: >>Compile time *is* an important issue, but the beauty of a header library >>is that there is no install step- you just copy the files into your >>directory tree. >Glyn Matthews wrote: >But there is an install step, because of the dependencies that cpp-netlib has - and will have: in developing the XMPP client I'll be linking to an XML parser >library and TLS library. Other protocol implementations will bring other dependencies and we'll have to deal with those too. Right now, the only required dependency that cpp-netlib has is boost, right? All I did to start using it was to copy it into my boost distribution. Granted, boost has an install step, but incrementally adding cpp-netlib (or updating to a newer version) just means copying header files right now. That makes it very easy to install/upgrade (unless you don't have boost yet). Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Glyn M. <gly...@gm...> - 2010-10-25 19:39:45
|
On 25 October 2010 21:20, Nelson, Erik - 2 <eri...@ba...>wrote: > >>Erik Nelson wrote: > >>Compile time *is* an important issue, but the beauty of a header library > >>is that there is no install step- you just copy the files into your > >>directory tree. > > >Glyn Matthews wrote: > >But there is an install step, because of the dependencies that cpp-netlib > has - and will have: in developing the XMPP client I'll be linking to an XML > parser >library and TLS library. Other protocol implementations will bring > other dependencies and we'll have to deal with those too. > > Right now, the only required dependency that cpp-netlib has is boost, > right? All I did to start using it was to copy it into my boost > distribution. Granted, boost has an install step, but incrementally adding > cpp-netlib (or updating to a newer version) just means copying header files > right now. That makes it very easy to install/upgrade (unless you don't > have boost yet). > > Right now, yes. And that's OK if you're already familiar with Boost (which is not always the case). But my main objection was motivated by trying to use dependencies outside Boost such as XML or cryptography libraries (I'd love to see Boost.XML or Boost.Crypto but we can't wait for these). CMake helps a lot here but it's easy to imagine that as the project grows the install/upgrade procedure needs to be managed very carefully too. IMO, libraries ought to be preferred to PCHs in this case. As a side note, maybe I can advertise what I've started for the XMPP client: http://github.com/glynos/cpp-netlib/tree/xmpp to let others know what kind of issues I am facing, and maybe I ought to start a new discussion to make progress on this. G |
|
From: Dean M. B. <mik...@gm...> - 2010-10-26 04:34:18
|
On Tue, Oct 26, 2010 at 2:59 AM, Glyn Matthews <gly...@gm...> wrote: > Hi, > > On 25 October 2010 16:32, Nelson, Erik - 2 <eri...@ba...> > wrote: >> >> > Dean Michael Berris wrote on Monday, October 25, 2010 >> >> > Now there are still a lot of other things I can do to start reducing >> > compile-times. One is incorporating precompiled headers into the >> > build, and start pre-compiling almost every single header in the >> > library. >> >> Pre-compiled headers seem like they are going to be a mess, and >> conceptually similar to going to a non-header-only implementation. I >> like the idea of header-only, but maybe a more library-based one would >> help the compile time. > > I agree with this point. IMO, although I agree that the header-only > approach has merits, it seems that since we're already requiring that users > link against Boost's system, regex and date_time libraries, we don't seem to > be gaining much from this approach anyway. Actually, I'll work on removing the dependency on Boost.Regex soon and use Boost.Xpressive instead to remove the link-time requirement to it. Date_time also has an option to inline everything (IIRC) while Boost.System will get a macro option to "inline" it. So pretty soon cpp-netlib can really be header-only depending on Boost. > Including the compile time > problem and making cpp-netlib strictly being header-only has very few > benefits. I would suggest a better use of our focus should be on > portability. Yeah, the compile time problem is really brought in by Boost.Spirit's Qi (and consequently Boost.Fusion and Boost.Proto). Although it is portable already as it is now, right? > Additionally, I have been doing a lot of development in embedded systems, > where the long compile times and large binaries that are generated pretty > much rules out using cpp-netlib. This is a shame, because this is an area > where cpp-netlib can provide a lot of benefits to developers. > Are you not stripping the binaries created by cpp-netlib? In Debug mode, yes you will have problems with the debugging symbols eating up the output binary. Also, since we still depend on Boost.Lexical_cast that does depend on the STL io streams library, that will cause the binaries to be pretty large. We might want to try using Jeroen's construe_cast in places where we use lexical_cast. The long compile times can really be addressed by precompiled headers especially if you're using GCC. Clang, well not so much because precompiled headers support is still a little ... well... iffy at this time. :D >> >> > Has anyone played around with CMake and how to make precompiled >> > headers part of the build process? I have seen some Google results on >> > the matter but I currently have no time/patience to muck around with >> > that. >> > >> >> Nothing else in Boost requires CMake, as far as I know. Boost-devel has >> had some rumblings about a change, but right now Boost.Build is the >> Boost standard. > > Sadly ;) > Yeah, it is sad. :D >> >> > I'm nearing the completion of the asynchronous server that invokes >> > request handlers in a thread pool and although the compile times have >> > been reduced in the HTTP client side of things I would really >> > appreciate some CMake kung-fu from people on the list to incorporate >> > precompiled-headers (so that we can make that part of the install step >> > in 0.8). >> > >> >> Compile time *is* an important issue, but the beauty of a header library >> is that there is no install step- you just copy the files into your >> directory tree. > > But there is an install step, because of the dependencies that cpp-netlib > has - and will have: in developing the XMPP client I'll be linking to an XML > parser library and TLS library. Other protocol implementations will bring > other dependencies and we'll have to deal with those too. Yeah, this is going to be the test of having an install step. :D > Regards, Thanks for the comments Glyn, hope mine help convince you that precompiled headers and changes to cpp-netlib will be good for users (and embedded systems). :) -- Dean Michael Berris deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-10-26 15:42:02
|
On 26 October 2010 06:33, Dean Michael Berris <mik...@gm...>wrote: > On Tue, Oct 26, 2010 at 2:59 AM, Glyn Matthews <gly...@gm...> > wrote: > > Including the compile time > > problem and making cpp-netlib strictly being header-only has very few > > benefits. I would suggest a better use of our focus should be on > > portability. > > Yeah, the compile time problem is really brought in by Boost.Spirit's > Qi (and consequently Boost.Fusion and Boost.Proto). Although it is > portable already as it is now, right? > Maybe I need to clarify what I meant "portable"... I mean that with each version upgrade of cpp-netlib we don't preserve backward compatibility either with older versions of Boost or of compilers. This pretty much rules it out for most embedded systems who have to rely on older compilers (for one project not so long ago I was still using gcc 2.95). I think there is a strong argument in favour of preferring this kind of stability than to using the latest and greatest from Boost (fun though it might be for the developers). > > > Additionally, I have been doing a lot of development in embedded systems, > > where the long compile times and large binaries that are generated pretty > > much rules out using cpp-netlib. This is a shame, because this is an > area > > where cpp-netlib can provide a lot of benefits to developers. > > > > Are you not stripping the binaries created by cpp-netlib? In Debug > mode, yes you will have problems with the debugging symbols eating up > the output binary. > > Also, since we still depend on Boost.Lexical_cast that does depend on > the STL io streams library, that will cause the binaries to be pretty > large. We might want to try using Jeroen's construe_cast in places > where we use lexical_cast. > > The long compile times can really be addressed by precompiled headers > especially if you're using GCC. Clang, well not so much because > precompiled headers support is still a little ... well... iffy at this > time. :D > and MSVC? I know it supports PCH of course but how does it differ from GCC? Will this affect design decisions? >> > I'm nearing the completion of the asynchronous server that invokes > >> > request handlers in a thread pool and although the compile times have > >> > been reduced in the HTTP client side of things I would really > >> > appreciate some CMake kung-fu from people on the list to incorporate > >> > precompiled-headers (so that we can make that part of the install step > >> > in 0.8). > >> > > >> > >> Compile time *is* an important issue, but the beauty of a header library > >> is that there is no install step- you just copy the files into your > >> directory tree. > > > > But there is an install step, because of the dependencies that cpp-netlib > > has - and will have: in developing the XMPP client I'll be linking to an > XML > > parser library and TLS library. Other protocol implementations will > bring > > other dependencies and we'll have to deal with those too. > > Yeah, this is going to be the test of having an install step. :D > > > Regards, > > Thanks for the comments Glyn, hope mine help convince you that > precompiled headers and changes to cpp-netlib will be good for users > (and embedded systems). :) > I am not going to argue too forcefully for shipping cpp-netlib as a library, since we've already been marketing it as header-only since it's inception and I think it does have merits. My main motivation is for better stability. Glyn |
|
From: Dean M. B. <mik...@gm...> - 2010-10-27 02:46:20
|
On Tue, Oct 26, 2010 at 11:41 PM, Glyn Matthews <gly...@gm...> wrote: > > > On 26 October 2010 06:33, Dean Michael Berris <mik...@gm...> > wrote: >> >> Yeah, the compile time problem is really brought in by Boost.Spirit's >> Qi (and consequently Boost.Fusion and Boost.Proto). Although it is >> portable already as it is now, right? > > Maybe I need to clarify what I meant "portable"... I mean that with each > version upgrade of cpp-netlib we don't preserve backward compatibility > either with older versions of Boost or of compilers. Hmmm... That threw me off. I thought you mean portable to different platforms, not backward compatible with older compilers or Boost versions. > This pretty much rules > it out for most embedded systems who have to rely on older compilers (for > one project not so long ago I was still using gcc 2.95). I think there is a > strong argument in favour of preferring this kind of stability than to using > the latest and greatest from Boost (fun though it might be for the > developers). > I think stability could be achieved in a different way. There are two ways I know of that allows us to go ahead and support more platforms+compilers: 1. Do a fork of the project that specifically addresses older compilers or specific platforms. This will mean porting to an older version of Boost and older version of compilers and fixing specific things that break for those compilers. You mention GCC 2.95 and that compiler version has the most compiler bugs and creates really bad code -- not to mention is not fully C++98 compliant IIRC. I've dealt with GCC 2.95 for an extended period of time early in my career and it's really frustrating having to work around its deficiencies when it comes to C++. 2. We do a branch that specifically addresses, for every release, the embedded platforms that we'd like to support. I can imagine for example porting cpp-netlib for meego or Symbian, but I'm really not prepared to take on that effort. ;) There might be other ways, but it's largely dependent on the available time/resource/expertise of contributors. :D >> >> The long compile times can really be addressed by precompiled headers >> especially if you're using GCC. Clang, well not so much because >> precompiled headers support is still a little ... well... iffy at this >> time. :D > > and MSVC? I know it supports PCH of course but how does it differ from GCC? MSVC has better support for PCH than GCC last time I checked. I didn't think it was worth mentioning because MSVC is also considerably faster than GCC IMO. ;) > Will this affect design decisions? Nope, not one bit. Just deployment/development strategies. :D >> >> Thanks for the comments Glyn, hope mine help convince you that >> precompiled headers and changes to cpp-netlib will be good for users >> (and embedded systems). :) > > I am not going to argue too forcefully for shipping cpp-netlib as a library, > since we've already been marketing it as header-only since it's inception > and I think it does have merits. My main motivation is for better > stability. I haven't been paying attention to stability at all lately because I still really just want to complete the features. It might be good to drop back to the requirement on Boost version -- going back to 1.41 would be a good idea by removing the dependency on Boost.Range extensions. Also, I have this (bad) habit of developing against Boost's trunk. My rationale is that it's easier to get acceptance to Boost if the library stays up to breast with the latest in the repository. Once things get to 1.0 though I really would like to focus on keeping the requirements on the Boost version low -- and by that time 1.45 might be the new "low stable" version given the Serialization SNAFU. ;) HTH -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-10-26 15:50:51
|
>Dean Michael Berris wrote: >The long compile times can really be addressed by precompiled headers >especially if you're using GCC. Clang, well not so much because >precompiled headers support is still a little ... well... iffy at this >time. :D Does gcc have any requirements on the usage of precompiled headers? I thought I remembered that no compilable code could appear before the precompiled header, which seems like it could lead to strange requirements like 'cpp-netlib headers need to be included first in a file' in order to get the pch benefit. I might be mistaken, just wanted to bring it up. Clang you don't have to worry about, since it's so fast already, right? ;) Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2010-10-27 02:59:39
|
On Tue, Oct 26, 2010 at 11:50 PM, Nelson, Erik - 2 <eri...@ba...> wrote: >>Dean Michael Berris wrote: >>The long compile times can really be addressed by precompiled headers >>especially if you're using GCC. Clang, well not so much because >>precompiled headers support is still a little ... well... iffy at this >>time. :D > > Does gcc have any requirements on the usage of precompiled headers? I > thought I remembered that no compilable code could appear before the > precompiled header, which seems like it could lead to strange > requirements like 'cpp-netlib headers need to be included first in a > file' in order to get the pch benefit. > Well, there's also the single PCH per compilation unit requirement. This would be perfect for 'boost/network/include/http/client.hpp' and similar files. http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html explains it in great detail. For the most part, these are easy -- and actually painless -- to follow in case you really want to get the advantage of PCH. Otherwise, that's not really a big burden having PCHs around if they're just there to help -- I mean, if they aren't used, the normal headers are used. > I might be mistaken, just wanted to bring it up. No worries. Thanks for bringing it up. :) > > Clang you don't have to worry about, since it's so fast already, right? > ;) > Hah! Touche. :) -- Dean Michael Berris deanberris.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X