Re: [Boost-users] Off topic: Interface / design question
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit, ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices. Hope this helps. -- Nikolai
Nikolai N Fetissov wrote:
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit,
ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices.
<rant> Presumably, you: 1. Have your CV somewhere online, that lists some serious projects done with both ACE and Boost. 2. Have a blog post or article that specifically names the "wrong design choices" that ACE forces one into? If so, can you provide links to those? </rant> I *don't* have direct experience with ACE, so I'm not going to defend it here, and I also assume you have good reasons to criticise ACE, but your email does not communicate them well. Calling a established project a "ugly, monolithic monster" without good justification written down does not seem a constructive, or fair, thing. Especially given that Boost is fairly monolithic and fairly big, too. - Volodya
1. Have your CV somewhere online, that lists some serious projects done with both ACE and Boost.
2. Have a blog post or article that specifically names the "wrong design choices" that ACE forces one into?
If so, can you provide links to those? </rant>
I *don't* have direct experience with ACE, so I'm not going to defend it here, and I also assume you have good reasons to criticise ACE, but your email does not communicate them well. Calling a established project a "ugly, monolithic monster" without good justification written down does not seem a constructive, or fair, thing. Especially given that Boost is fairly monolithic and fairly big, too.
Staying on the positive side of the discussion, I'll put in my two pennies worth, and describe my evaluation journey through various inter-process communication libraries. I've started working on a number of distributed system projects. As a consequence, I started looking for distributed system libraries. References to ACE were most pervasive. I implemented a number of trial applications with the library. That was after plowing through relevant sections in the three primary ACE reference books. That was a good learning experience, if only to find out the various patterns in distributed architecture definition. I had the inter-process/inter-server communications (which only sent simple stuff) working well within ACE's Acceptor/Connector framework. ACE has a number of other patterns one can use. I was really impressed with the fact that the examples I used from the books worked as advertised, and I was able to bend them to my will. ACE is based upon an interaction of classes, macros, and templates. One has to spend some time with the environment in order to become proficient with it. It has a large API. A number of lower level API's upon which higher level API's are based. For example the Acceptor/Connector uses constructs described earlier in the books. Once I had my basic communications going, I realized I needed to get some form concrete messaging infrastructure in place. I had an impression that TAO, which is a layer above ACE, would be quite extravagant to implement, with it being an implementation of the CORBA specification. I wanted something a little lighter (a whole lot lighter actually). As I worked through that project, I started hearing about ASIO, indirectly through some other libraries I was using. ASIO is now a member of Boost. I read a review somewhere that ASIO is a 'modern' replacement for ACE. If you want to get into real template structures and Boost oriented philosophy, I'd say that is a valid statement. I'd also say that ASIO is 'more to the point' and straight forward than is ACE, at least for the things I want to accomplish. But like ACE, ASIO is the basic communications infrastructure, no real messaging capability, which is what distributed computing is all about. ASIO turned out to be a little harder to get my head wrapped around as it uses a number of advanced C++ and Boost related idioms. For a run-of-the-mill C++ programmer, ACE would be better. For someone steeped in the power and obscurity of advanced C++, and is looking to advance their skill set, ASIO would be better. I came across RCF (http://www.codeproject.com/KB/threads/Rcf_Ipc_For_Cpp.aspx), which is a messaging framework riding atop of ASIO. Flexible, lightweight, and to the point. I worked through the examples and things worked as advertised. It has the encryption, publisher/subscriber, oneway/twoway idioms, and a few other nifty features. At the same time I was doing that, seemingly coincidently, I learned a few more interesting facts. Going into this, I realized that I need a message dispatcher/proxy, some decent failover techniques, and some additional event handling for non-IPC related activities. Someone suggested ICE from www.zeroc.com for an RCF-like solution, but working to a larger scale. I've heard that the library's originator is someone who spent much time on CORBA standards and redid the concept without the 'benefit' of committee involvement. I think the library has all the bases covered in terms of lightweight message handling, dispatching, resiliency, and higher level distributed processing philosophies. The drawback is that it will have a steeper learning curve than would an implementation using RCF. I like RCF, but I think I'm going to have to tilt towards ICE (itself, like RCF, developed and focused towards C++ in a multiple license environment). On the non-IPC front, Qt's QCoreApplication looks to be a good substrate on which to build event driven daemons. In the end, I think my solutions are going to involve: * ZeroC's ICE for primary inter-process communications * a little legacy layer 3/4 ACE in one library I'm using, but with some work, I think I can convert the ACE stuff to ASIO * Qt QCoreApplication as a base for daemon development (which has built-in stuff for threads/locks, slots/signals) * http://www.webtoolkit.eu/wt/, a C++ based web toolkit for distributed GUI development * boost libraries to fill in all the little holes Hopefully this didn't turn out to be too off topic. Ray. -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.
Appreciate your inputs. Is there an open source library/framework similar to what Tibco rvd does? -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Ray Burkholder Sent: Thursday, May 29, 2008 12:13 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Off topic: Interface / design question
1. Have your CV somewhere online, that lists some serious projects done with both ACE and Boost.
2. Have a blog post or article that specifically names the "wrong design choices" that ACE forces one into?
If so, can you provide links to those? </rant>
I *don't* have direct experience with ACE, so I'm not going to defend it here, and I also assume you have good reasons to criticise ACE, but
your email does not communicate them well. Calling a established project a "ugly, monolithic monster" without good justification written down does not seem a constructive, or fair, thing. Especially given that Boost is fairly monolithic and fairly big, too.
Staying on the positive side of the discussion, I'll put in my two pennies worth, and describe my evaluation journey through various inter-process communication libraries. I've started working on a number of distributed system projects. As a consequence, I started looking for distributed system libraries. References to ACE were most pervasive. I implemented a number of trial applications with the library. That was after plowing through relevant sections in the three primary ACE reference books. That was a good learning experience, if only to find out the various patterns in distributed architecture definition. I had the inter-process/inter-server communications (which only sent simple stuff) working well within ACE's Acceptor/Connector framework. ACE has a number of other patterns one can use. I was really impressed with the fact that the examples I used from the books worked as advertised, and I was able to bend them to my will. ACE is based upon an interaction of classes, macros, and templates. One has to spend some time with the environment in order to become proficient with it. It has a large API. A number of lower level API's upon which higher level API's are based. For example the Acceptor/Connector uses constructs described earlier in the books. Once I had my basic communications going, I realized I needed to get some form concrete messaging infrastructure in place. I had an impression that TAO, which is a layer above ACE, would be quite extravagant to implement, with it being an implementation of the CORBA specification. I wanted something a little lighter (a whole lot lighter actually). As I worked through that project, I started hearing about ASIO, indirectly through some other libraries I was using. ASIO is now a member of Boost. I read a review somewhere that ASIO is a 'modern' replacement for ACE. If you want to get into real template structures and Boost oriented philosophy, I'd say that is a valid statement. I'd also say that ASIO is 'more to the point' and straight forward than is ACE, at least for the things I want to accomplish. But like ACE, ASIO is the basic communications infrastructure, no real messaging capability, which is what distributed computing is all about. ASIO turned out to be a little harder to get my head wrapped around as it uses a number of advanced C++ and Boost related idioms. For a run-of-the-mill C++ programmer, ACE would be better. For someone steeped in the power and obscurity of advanced C++, and is looking to advance their skill set, ASIO would be better. I came across RCF (http://www.codeproject.com/KB/threads/Rcf_Ipc_For_Cpp.aspx), which is a messaging framework riding atop of ASIO. Flexible, lightweight, and to the point. I worked through the examples and things worked as advertised. It has the encryption, publisher/subscriber, oneway/twoway idioms, and a few other nifty features. At the same time I was doing that, seemingly coincidently, I learned a few more interesting facts. Going into this, I realized that I need a message dispatcher/proxy, some decent failover techniques, and some additional event handling for non-IPC related activities. Someone suggested ICE from www.zeroc.com for an RCF-like solution, but working to a larger scale. I've heard that the library's originator is someone who spent much time on CORBA standards and redid the concept without the 'benefit' of committee involvement. I think the library has all the bases covered in terms of lightweight message handling, dispatching, resiliency, and higher level distributed processing philosophies. The drawback is that it will have a steeper learning curve than would an implementation using RCF. I like RCF, but I think I'm going to have to tilt towards ICE (itself, like RCF, developed and focused towards C++ in a multiple license environment). On the non-IPC front, Qt's QCoreApplication looks to be a good substrate on which to build event driven daemons. In the end, I think my solutions are going to involve: * ZeroC's ICE for primary inter-process communications * a little legacy layer 3/4 ACE in one library I'm using, but with some work, I think I can convert the ACE stuff to ASIO * Qt QCoreApplication as a base for daemon development (which has built-in stuff for threads/locks, slots/signals) * http://www.webtoolkit.eu/wt/, a C++ based web toolkit for distributed GUI development * boost libraries to fill in all the little holes Hopefully this didn't turn out to be too off topic. Ray. -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
Appreciate your inputs. Is there an open source library/framework similar to what Tibco rvd does?
For what type of features are you looking? -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit,
ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices.
<rant> Presumably, you:
1. Have your CV somewhere online, that lists some serious projects done with both ACE and Boost.
2. Have a blog post or article that specifically names the "wrong design choices" that ACE forces one into?
If so, can you provide links to those? </rant>
I *don't* have direct experience with ACE, so I'm not going to defend it here, and I also assume you have good reasons to criticise ACE, but your email does not communicate them well. Calling a established project a "ugly, monolithic monster" without good justification written down does not seem a constructive, or fair, thing. Especially given that Boost is fairly monolithic and fairly big, too.
- Volodya
This comes from direct experience with ACE. The library is full of evil macros, deep inheritance trees, C-style casts, etc. It hurts to even look at the source. It was built around early weak compilers and it shows. As for being monolithic - how about a single 5 MB shared library? All or nothing. With Boost I at least have a choice of what to build and what to link with. Take a look at their docs - you'll understand: http://www.dre.vanderbilt.edu/Doxygen/5.6.5/html/ace/index.html As for wrong design choices - just pickup a copy of "C++ Network Programming" (either volume) by D. Schmidt, et al. and see if you can honestly recommend it to anybody. If you're so inclined, you can find my CV and rants at www.fetissov.org. -- Nikolai
I think the OP is from Lehman and you probably know about the recent error blamed on a computer glitch at MCO, http://www.bloomberg.com/apps/news?pid=20601087&sid=ar.8vyi373ZY&refer=home Computing in financial services can be high profile and it isn't always clear exactly what priorities you have in such a setting. Maybe Java would be a better choice just because it is harder to create computer related ( things like memory corruption ) problems. Testing numerical code and design approaches to insure you don't get things like round off error, even with fixed point money things, can be important ( with java, you should be able to diff most numerical output as it is suposed to always have IEEE floating point and therefore reproducible roundoff etc ). Anyway, that was what provoked my earlier question about overall interests. I am happy to see a recognition that compilers, even today, are not omniscient oe consistent with obscure syntax handling, some aren't even cache aware :)
Date: Thu, 29 May 2008 12:22:21 -0400 From: nikolai-boost@fetissov.org To: boost-users@lists.boost.org Subject: Re: [Boost-users] Off topic: Interface / design question
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit,
ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices.
Presumably, you:
1. Have your CV somewhere online, that lists some serious projects done with both ACE and Boost.
2. Have a blog post or article that specifically names the "wrong design choices" that ACE forces one into?
If so, can you provide links to those?
I *don't* have direct experience with ACE, so I'm not going to defend it here, and I also assume you have good reasons to criticise ACE, but your email does not communicate them well. Calling a established project a "ugly, monolithic monster" without good justification written down does not seem a constructive, or fair, thing. Especially given that Boost is fairly monolithic and fairly big, too.
- Volodya
This comes from direct experience with ACE. The library is full of evil macros, deep inheritance trees, C-style casts, etc. It hurts to even look at the source. It was built around early weak compilers and it shows. As for being monolithic - how about a single 5 MB shared library? All or nothing. With Boost I at least have a choice of what to build and what to link with. Take a look at their docs - you'll understand: http://www.dre.vanderbilt.edu/Doxygen/5.6.5/html/ace/index.html As for wrong design choices - just pickup a copy of "C++ Network Programming" (either volume) by D. Schmidt, et al. and see if you can honestly recommend it to anybody.
If you're so inclined, you can find my CV and rants at www.fetissov.org. -- Nikolai
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_________________________________________________________________ Keep your kids safer online with Windows Live Family Safety. http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_Ref...
Nikolai N Fetissov wrote:
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit,
ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices.
<rant> Presumably, you:
1. Have your CV somewhere online, that lists some serious projects done with both ACE and Boost.
2. Have a blog post or article that specifically names the "wrong design choices" that ACE forces one into?
If so, can you provide links to those? </rant>
I *don't* have direct experience with ACE, so I'm not going to defend it here, and I also assume you have good reasons to criticise ACE, but your email does not communicate them well. Calling a established project a "ugly, monolithic monster" without good justification written down does not seem a constructive, or fair, thing. Especially given that Boost is fairly monolithic and fairly big, too.
- Volodya
This comes from direct experience with ACE.
Good.
The library is full of evil macros, deep inheritance trees, C-style casts, etc. It hurts to even look at the source. It was built around early weak compilers and it shows.
This all looks like style issues. Does it actually contain any design issues that lead to buggy code, or make it more harder to write code. Is all ACE functionality now present in boost?
As for being monolithic - how about a single 5 MB shared library? All or nothing. With Boost I at least have a choice of what to build and what to link with.
That's just a different tradeoff. With ACE, you have 5MB of shared library code. With Boost, you have unknown amount of headers included into every translation unit, and then compiled into each of your application. There's no hard data how much that is, exactly.
Take a look at their docs - you'll understand: http://www.dre.vanderbilt.edu/Doxygen/5.6.5/html/ace/index.html As for wrong design choices - just pickup a copy of "C++ Network Programming" (either volume) by D. Schmidt, et al. and see if you can honestly recommend it to anybody.
I'll have trouble recommending certain parts of Boost, either.
If you're so inclined, you can find my CV and rants at www.fetissov.org.
Thanks. Of course, mentioning that you've worked with ACE, and giving specific (non-style) issues you've run into, would be better information to OP. - Volodya
Appreciate your response. Any thoughts on why the designers of boost decided not to write interfaces for their classes? -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Nikolai N Fetissov Sent: Wednesday, May 28, 2008 10:54 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Off topic: Interface / design question
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit, ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices. Hope this helps. -- Nikolai _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
Khandelwal, Amit wrote:
Appreciate your response. Any thoughts on why the designers of boost decided not to write interfaces for their classes?
I assume, you ask why boost does not generally provide functionality via polymorphic classes free of non-static data members? If so, the answer is rather simple: They follow the basic principle in the C++ world, that you should not pay for what you did not ask. It is always possible (for you!) to wrap any concrete class behind such an "interface", but it is not generally possible to obtain the maximum advantages of statically known classes, inlining, etc, if that what you get is a firewall interface. Greetings from Bremen, Daniel Krügler
If you don't mind me asking, what type of applications are you targeting ( modelling, simulation, accounting, etc) and have you historically used something like MFC, or some other language like java? Thanks. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: Hotmail is possibly blocking my mom's entire ISP - try me on marchywka@yahoo.com if no reply here. Thanks. ----------------------------------------
Date: Thu, 29 May 2008 08:43:12 -0400 From: amit.khandelwal@lehman.com To: boost-users@lists.boost.org Subject: Re: [Boost-users] Off topic: Interface / design question
Appreciate your response. Any thoughts on why the designers of boost decided not to write interfaces for their classes?
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Nikolai N Fetissov Sent: Wednesday, May 28, 2008 10:54 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Off topic: Interface / design question
Background: I am/was planning to profile the thread libraries from boost and ACE. During this experiment, I wish we had an interface class defined for threads. Also, I wish boost and ACE had implemented those interface classes. It would have helped someone like me profile different C++ libraries with ease.
I was going through the header files of boost and I don't see a interface classes being used. I am trying to understand was there a conscientious decision made to not define them. I am trying to understand the reason behind those decisions. It will help newbie's like me to understand C++ better and write better code.
Amit,
ACE and Boost are unrelated projects, and there's no universal thread "interface" to implement. This doesn't mean you can't design thin wrappers yourself for your experiment. Honest advise though - do not use ACE, even if you find it faster, which I very much doubt. Boost is a set of modern C++ libraries, pushing its way into standard C++, and developed by world experts; while ACE is dated, ugly, monolithic monster that forces you into wrong design choices.
Hope this helps. -- Nikolai
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
-------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_________________________________________________________________ Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause
participants (6)
-
Daniel Krügler -
Khandelwal, Amit -
Mike Marchywka -
Nikolai N Fetissov -
Ray Burkholder -
Vladimir Prus