March 2005 - Boost - lists.boost.org

offline code generator for BIL
by christopher diggins 09 Mar '05

09 Mar '05

I just wanted to put forth that I really could use an offline code generator for my work on the OOTL. I only want a handful of interfaces for the library which won't change often. The benefits for me are: a) I won't have extra boost dependencies for meta-programming b) have the fastest possible compile times for my library Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 5

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 09 Mar '05

09 Mar '05

In-Reply-To: <422EFC7F.9D48D181(a)tid.es> joaquin(a)tid.es (=?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?=) wrote (abridged): > Oh, sorry, I misread it. I agree with you hashing a bool makes little > sense, and agree that it probably shouldn't be made part of the public > interface (for the same reasons, for instance, that there's no overload > for char.) Is that because bools and chars will be promoted to ints? I can imagine wanting bools and chars to hash differently, to take advantage of their special properties. Then hash_value('\0') could be different to hash_value(0), which wouldn't bother me because they are different types. However I can understand if this is felt too risky for general use. -- Dave Harris, Nottingham, UK

1 0

Re: [review] hash functions
by Jaap Suter 09 Mar '05

09 Mar '05

I would like to second the following: "1. The overloads of hash_value for STL containers forces the implementation to include <vector>, <list>, etc., which makes the header a little heavier than desired." I'd say it's not a 'little' heavier but a lot heavier. Can we not put the extensions in their own header files; vector_hash.hpp or something? Not everybody has all these containers in a precompiled header already. Thanks, Jaap Suter

3 2

Logo Contest Current Tally
by Joel de Guzman 09 Mar '05

09 Mar '05

Hi, You can see the latest logo contest tally here: http://boost.org/more/logo_contest_tally.htm As of March 7, 2005: Votes Entry 6 38, Simeon Nasilowski 5 67, Simeon Nasilowski 4 39, Simeon Nasilowski 4 75, Zoltan "cad" Juhasz 3 83, Emil Kirichev 3 85, Ben Hetland 3 92, Aleksey Gurtovoy 2 18, Boost 2 Jonathan Turkanis 2 52, Zoltan "cad" Juhasz 2 60, Banu Alexandru 2 68, Aleksey Gurtovoy 1 1, Boost 1 13, René Rivera 1 20, Jonathan Turkanis 1 23, Jonathan Turkanis 1 29, Erik Wien 1 3, Joaquín M López Muñoz 1 30, Erik Wien 1 62, Mike H 1 97, Jonathan Turkanis 1 18, Jonathan Turkanis Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

15 39

Re: [boost] Re: RPC library
by Iain Hanson 09 Mar '05

09 Mar '05

On Thu, 2005-03-03 at 22:28 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > [snip] > You're making my point for me. For something quick and dirty, who is going to > want to type all that out? And before I do, I have to learn about IDL, _var > types, safe downcasts, factories, CORBA::string's, etc, while in the back of my > mind there's the nagging suspicion that I've missed some subtle detail > somewhere. I hardly find 5 lines of code onerous. And it is easy to wrap up part of it in a template. Quick and dirty may be something you do to learn how to do something. But AFAIK, not something we create boost libraries for. IDL is what gives you type safety, something we usually appreciate in C++. > And whoever will be looking at my code needs to learn these things as > well. This is something that never fails to amaze me. Building distributed systems is hard to do correctly. It is very similar to the difficulty with threaded systems but the issues are subtly different and I think harder in distributed systems. If you can't learn a few conventions in half a day, then you probably have no business trying to build such systems. I probably spend half of my working life fixing systems that have been quickly hacked and then put into production. CORBA /EJB both have marketed themselves as the easy and safe way to write distributed systems and they are not. They are easy to write bad systems in. What you are proposing is an easier way to write even worse systems. > I also have to modify the build process to handle the IDL files, and then > find an ORB to build and link to. None of this is difficult, but I personally > find it rather cumbersome, and above all, for my situation it's just plain > unnecessary. All I wanted to do was to make a couple of remote calls between two > C++ programs! Something along these lines seems to me much more proportional to > the task at hand: You already have to link to the serialization library that you have had to build. I don't understand the difference. And your user needs to understand the trade-offs with each archive format. > > // server > > RCF_BEGIN(I_Echo, "I_Echo") > RCF_METHOD_R1(std::string, echo, std::string); > RCF_END(I_X); > > struct Echo > { > void std::string echo(std::string s) { return s; } > }; > > int main() > { > RCF::RcfServer server(50001); > server.bind<I_Echo,Echo>(); > server.start(); > return 0; > } > > // client > > RCF_BEGIN(I_Echo, "I_Echo") > RCF_METHOD_R1(std::string, echo, std::string); > RCF_END(I_Echo); > > int main() > { > std::cout << RcfClient<I_Echo>("localhost", 50001).echo("ho hum"); > return 0; > } > Your client has 4 lines of code to my 5 and you have macros in your interface. Not normally considered a good thing. And you have hard coded the server location. Always considered a bad thing in anything but toy code. [snip] > I guess the argument boils down to this: does anyone write network applications > for which CORBA-style scaleability is not a requirement? I would think so, but > maybe I'm wrong. > There are low level systems that need to work with sockets. The IETF has made a pretty good job of making the internet protocols scale. And there are hard and soft real time projects that need to use sockets. There are probably a lot of applications that have been built using sockets that should have used CORBA. Cost has historically been a big issue with CORBA because commercial implementations have typically ( in the U.K. ) cost of the order of £3,500 per developer a year and £2,500 per user a year run time. > RPC's don't scale too well, we both agree on that. But why do you think all > applications need to scale? If I'm prototyping something, then the last thing in > the world I need is scaleability, and I certainly wouldn't want the development > cluttered and slowed because someone has decreed that we must all use CORBA > because it scales so well. > If you are just playing around then I don't have a problem. But I don't think boost is in the habit of adopting toys. The problem with over simplified solutions is that a prototype is built, the boss asks for a few extra features, and before you know it, its rolled out to production and know one will pay for it to be re-written properly :-(. > Your position seems to be that programmers should not be afforded the option of > choosing; they should just bite the bullet and always use CORBA. If they don't > like that, then they should just avoid networking altogether. Personally I tend to prefer not letting programmers shoot themselves in the foot, if I can avoid it. Unfortunately, they ( and I sometimes ) are incredibly inventive at finding new ways to do so ;-). /ikh

7 11

N-arity operators in C++, also reducing temporaries. [Repost]
by Pavel Chikulaev 09 Mar '05

09 Mar '05

This text not as silly as my "Herb Sutter's operator = can be optimized", so please read it. I'm currently working on library "Lazy" which eases creation of classes which needs lazy evalution and n-arity operators to improve speed. The library's sample usage placed below. Please let me know what do you think about it. I'll appreciate any feedback on my library. Library description: Library eases creation of classes which needs lazy evalution and n-arity operators. Library features are: * n-arity operators support; * operator aliasing, such as a + -b will be computed as a - b; * custom operators; * no unnecessary temporaries during evalution and assigning. Library's sample usage: //Matrix.h #include "lazy.hpp" class transpose_tag {}; //Tag class class Matrix { LAZY_CLASS(Matrix) static lazy::type<Matrix> Matrix_; //Similar to Andrei Alexandrescu's Type2Type template public: Matrix(); Matrix(const Matrix &); Matrix & operator = (const Matrix &); void swap(void Matrix &); //Libray won't work without swap function. //If name of your swap function isn't swap then use //LAZY_CLASS_EX(Matrix, YourSwapFunctionName) //lazy constuctors which enables lazy operators Matrix(LAZY_OP(Matix_ + Matrix_)); //Matrix operator +(Matrix, Matrix) Matrix(LAZY_OP(Matrix_ * Matrix_)); //... Matrix(LAZY_OP(-Matrix_); Matrix(LAZY_OP(Matrix_ + Matrix_ * Matrix_)); //ternary operator //Now enable operators LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ * Matrix_); LAZY_ENABLE_OP(Matrix_ = -Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_ * Matrix_); //operator aliasing LAZY_ALIAS(Matrix + -Matrix_ = Matrix_ - Matrix_); //Custom operation Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_))); LAZY_ENABLE_CUSTOM_OP(transpose, Matrix_ = lazy::custom_op<transpose_tag>(Matrix_)); //same as Matrix transpose (const Matrix &) but there //won't be any temporary objects at all }; //Matrix.cpp Matrix::Matrix(LAZY_OP(Matix_ + Matrix_) op) { //Construct matrix object //lhs matrix = op._1 //rhs matrix = op._2 } Matrix::Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_) op) { //Construct matrix object tranposed to op._1 } //etc //Now the use of Matrix class Matrix a, b, c, d; //... a = b + c; //No tempories at all //Using normal practice it will take two temporary objects (no NRVO or RVO ) a = b + -c; //Will be evaluates as a = b - c; No temporaries again //Using normal practice it will take three temporary objects (no NRVO or RVO) a = b + c * d; //Will use ternary operator. No temporaries again a = transpose(b); //Custom lazy operation. No tempories again Maybe the library is very similar to uBLAS's matrix_expression and vector_expression. But with my approach there is no need to code matrix_expression and vector_expression at all and it is easy to create new classes which needs lazy evaluation and n-arity operators. I believe that my library should be very useful with big_int. So what do you think? Is there any similar approaches available? Is there any need of such library? Thanks in advance. -- Pavel Chikulaev

7 47

Herb Sutter's Assignment operator can be optimized + Proposal for very small boost utility library
by Pavel Chikulaev 09 Mar '05

09 Mar '05

Hi, Do you know that well-known Herb Sutter's assignment operator in most cases does unnecessary copying? No? Then read it to learn how to elminate it. class Matrix { //.... Matrix& operator = (const Matrix& that) { Matrixtemp(that); swap(temp); return *this; } //... }; Consider first example: Matrixa, b; //.... a = b; Here Herb Sutter's operator = works just fine. But consider second example: Matrix func (); Matrix a; //... Matrix = func(); Result of func() is copied to temporary objectand then operator = copies it again. So assigning to result of function creates one useless object. Elminating of temporary int object will cost nothing, but elminating of temporary std::vector of 10000 elements will cost a lot. But how can we define that copying is necessary? - Every function returns object not of type T but temporary object of type T. So let's code something: template<typename T> struct temporary : T { temporary() {} temporary(const T & t) : T(t) {} //some operators and constructors to create base object in-place not listed here }; Now let's change function consider operator +: Matrix operator + (const Matrix & a, const Matrix & b) { Matrix temp(a); temp += b; return temp; } To optimize it we do the following: temporary<Matrix> operator + (const Matrix & a, const Matrix & b) { Matrix temp(a); temp += b; return temp; } Maybe it can be hardly optimized using NRVO, so let's help the complier rewriting as following: temporary<Matrix> operator + (const Matrix & a, const Matrix & b) { temporary<Matrix> temp(a); temp += b; return temp; } By now, even returning temporary<Matrix> instead of Matrix, no optimization is done. To enable the optimization we need to change the class Matrix by adding one more assignment operator : Matrix & operator = (const temporary<Matrix> & that) { swap (const_cast<Matrix &>(static_cast<const Matrix &>(that))); return *this; } or using "deprecated" casts Matrix & operator = (const temporary<Matrix> & that) { swap ((Matrix &) that); return *this; } By now we've elminated unnecassary copying. Is this worth being called Pavel Chikulaev's temporary assignment operator? Is this worth being included in Boost? By including temporary.hpp, adding one operator in class, and replacing each function result to explicitly marked temporary you get really a lot. My temporary assignment operator as safe as Herb Sutter's. Maybe returing temporary<T> will make some obstacles to templated programming, so i'm going to add temporary_traits: is_temporary, add_temporary, remove_temporary. Some changes of BOOST_TYPEOF will be also needed. So, what do you think? Copyright 2005 Pavel Chikulaev. Use, modification, and distribution are subject to the Boost Software License, Version 1.0

12 29

Sockets
by Boris 09 Mar '05

09 Mar '05

There hasn't been much talk about a socket library recently. The Wiki stuff about sockets is quite old so I don't know if Hugo is still working on it? It's some time ago I added some proposals for a multiplexing library to the Wiki. So I went through most of the Wiki pages of Boost.Socket and Multiplexing and tried to gather and sort the ideas a bit. As I don't want to go even more into details by adding more C++ code I tried a top-down-approach using UML diagrams. Without sorting the ideas and getting a big picture we are stuck in the details and don't proceed. The network API isn't small, there are many different goals to reach and the network library might overlap with other libraries - quite a lot to do. :-) So here is the next small step: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet As usual any comments are appreciated, Boris

7 13

Boost 1.32.0 and VS.NET 2005 under AMD64
by p.klotz＠icoserve.com 09 Mar '05

09 Mar '05

Hi I have sent a mail about this topic to boost-users a few weeks ago but got no response. There exist a few problems when trying to compile Boost 1.32.0 under AMD64 with VS.NET 2005: * No toolset exists to compile Boost 1.32.0 native on the AMD64 platform (no cross compile). The attached file vc-8_0-amd64-tools.jam fixes that. * InterlockedExchange() in line 44 of lwm_win32.hpp collides with a macro of the same name in WinBase.h One finds in WinBase.h: #elif defined(_M_AMD64) && !defined(RC_INVOKED) ... #define InterlockedExchange _InterlockedExchange I changed the name of Boost's function to InterlockedExchangeBoost() to avoid this problem. * No type long_type exists when compiling with the Microsoft Compiler. The 64Bit part in lwm_win32.hpp seems to have been written for the Intel Compiler. An additional #ifdef now checks if the 64Bit compiler is from Intel or Microsoft. The InterlockedExchange() and long_type issues are fixed by boost_1_32_0-AMD64.patch. Maybe these changes can be integrated in some form in the next version of Boost. Best regards, Peter.

2 2

Re: [boost] [1.33.0]: Some Moderation Please.
by Dave Gomboc 09 Mar '05

09 Mar '05

> Date: Tue, 08 Mar 2005 13:50:54 -0700 > From: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > > And I _hope_ what I put in the <hostile>...</hostile> was offensive, > it was intended to be. I'd hate to think that I'm accidently offensive > but can't be when I want to. Victor, please, quit while you're behind. Dave

1 0

[testing] Possible changes to testing..
by Rene Rivera 09 Mar '05

09 Mar '05

All, I've been reading all the testing related post and not having time to respond to them. So I decided to talk about what might be done to improve things in one big posting. For along time now one of my objectives has been to use BuildBot (http://buildbot.sf.net/) to improve the management of running the regression tests. For those who don't feel like reading about that software here's a quick summary: It is a client-server based configuration where the test server controls the test clients telling them what to do for test. In this arrangement the client do not directly control what they are testing, nor how. All the clients provide is an execution environment for the testing. The server is configured to control the various clients as to what they test, including how to get the source, and when they test. The testing is change driven instead of time driven as we currently have. This means that each time a change occurs on the source (CVS in our case) the server decides to tell the clients to run tests. Because of this direct communication to the clients the server is able to give direct feedback as to what the testing is doing. This includes a live display of test progress, down to a dynamic view of the test log. Some of the issues and how this step might help. And other changes I've thought about might help.. *Reproducibility* BuildBot controls what the checkouts are and what triggered the build. You can see this by selecting one of the yellow "Build #" links on the BuildBot display. If there's ever a question about what code produced an error one can get the specific version of the tree to attempt reproduction. The history of what tests have run is kept. Which means that we can finally answer the dreaded "When did that start breaking?" question. *Scalability* One big change I'd like to see is the breakup of running tests to make it possible for testers to run tests on subsets of libraries, or even individual libraries. For example there might be some testers which have a special interest in a particular library, Boost.Python comes to mind. It would be ideal to make it possible for them to only run those tests, and to go through the extra steps of doing the Python setup. Also for some popular platforms, it becomes possible to get much faster response rates from testing if, for example, we partition the library testing space throughout those platforms and they would test the libraries in parallel. For this to happen some significant organizational changes need to happen to the tests. As it currently stands such a division is not possible because of the way tests are defined and organized. We have a single test point, status/Jamfile, which a) points to the rest of the test points, libs/*/test/Jamfile, and b) defines it's own tests. The problem is that there is a conflict, for some libraries, between the tests defined in status/Jamfile, and the tests defined in libs/*/test/Jamfile. For example Boost.Config has a reduced set of test in status/Jamfile. This situation is likely a reaction to reduce test times to something manageable. And I understand that library authors would need to have a place to run their own set of comprehensive tests. My proposal is to create a set of canonical tests that comprise the regression testing suite independent of the library author's tests. This set of tests would be structured so that it's possible to run each libraries tests independent of others. It would be adding this type of structure: boost-root/tests/<library>/Jamfile boost-root/tests/<library>/<sub-library>/Jamfile boost-root/tests/<library>/<some-other-grouping>/Jamfile So for example a tester could say she only wants to test python/*, or numeric/ublas/*, etc. *Fragility* Simply put because BuildBot exposes the complete testing procedure it becomes much easier to see where problems occur in the testing. Also, because there is a central server managing the procedures it's more likely that problems can be solved at that one location instead of opaquely trying to fix the clients. With the, hopefully, additional distributed testers it becomes harder for testing to break down completely. Another aspect we need to address is fragility of the server. Ideally we would have multiple BuildBot servers to add redundancy. To make such a multi-server, multi-client setup resource efficient we would need to manage the distribution of testing between them. *Resources* The only predictable way to address the resource usage, is to distribute the testing so we can create more capacity. Breaking up the tests is the only way I can see to move there. It was already suggested that only slicing the testing to single toolsets would help. But that doesn't really address the problems. For example it would still be prohibitive for me to run tests on my G3 Mac for CW-8.3 because it's a slow machine and it would take days to run just one cycle of tests making the results useless. But it would be possible for me to run a minimal set of tests, for example Boost.Config and other basic tests. Restructuring also brings up the possibility of moderating the set of tests that make it into the regression suite. Right now we are in a position of asking library authors to define what the tests for the library. We can't moderate what gets into testing, or what needs go out. We need some procedure for reviewing tests, and some form of approval to get tests into the regression system. I'm not saying that authors would not be able to do additional testing, just that we need to define what the standard set of tests are so that we can concentrate our testing efforts. It would still be possible to set up additional resources to run "experimental" tests. *Response* The gain from segmentation and distribution of testing is hopefully obvious ;-) But another advantage of using BuildBot is that we are not tied to waiting for the XSLT processing to see results. Sure the results are not going to be as incredibly well organized as the Meta-Comm results but they are immediately available. So if there is a significant delay in the processing, because of load or breakage, we can still continue working. *Releases* Managing the testing for a release was brought up a many times. And it's clear that requiring testers to do manual changes is just not working. For BuildBot having the control of what is tested on the server means that at any point one, or some small number, person(s) can make the switch to have testing resources devoted to release testing. One possibility that the finner grain testing allows for is to limit the testing for a release to the required set of toolsets and platforms. OK, that's enough rambling... I know I haven't mentioned many other items raised, particularly about bjam and Boost.Build. I'll leave that for another post. I just need to get back to setting up the BuildBot server now ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

RE: [boost] thread safety in boost date time
by Yitzhak Sapir 09 Mar '05

09 Mar '05

> From: Jeff Garland > > On Tue, 8 Mar 2005 11:34:15 +0200, Yitzhak Sapir wrote > > Boost date_time apparently has a thread safety problem in linux in > > that it calls localtime() in boost/date_time/time_clock.hpp and > > related functions rather than localtime_r() and related functions. > > This is even though BOOST_HAS_PTHREADS is defined by configure in > > user.hpp. > > That's true -- date_time doesn't do anything to ensure thread > safety. I'm a little reluctant to protect these functions since the > user can determine better if they need to take the associated > performance hit. Of course this needs to be documented, which > it isn't now. Thoughts? Ok, having investigated the problem a little more, I get the following.. The problem comes down to the fact that localtime/gmtime call tzset(), which in turn calls getenv("TZ"). This call isn't done in the _r versions which use pretty much the same code. getenv() appears to be not thread safe, but I'm not sure why. This does indicate, however, that probably the _r versions are a little quicker (because they don't call getenv()). Running localtime (no _r) in loops in four threads on a multi cpu machine resulted in no segmentation fault. Maybe something else is interfering with getenv() in unforseeable ways? boost is not the only one making these calls. log4cxx is another third party we use and it also makes these calls. It also calls wcsftime, a version of strftime, which appears to always call tzset()/getenv(). So, wcsftime/strftime appear to be not threadsafe either. For the record, we use libgcc 3.3.3 and glibc 3.2.3. The libgcc is a by product of compiling an equivalent gcc on all machines for distcc purposes, while the glibc is the version that was installed with the operating system. I am wondering if this version mismatch could be the cause of the problems, but it seems the getenv.c hasn't changed in glibc for 2 years. A link to an example posting about a problem that seems very similar: http://lists.gnu.org/archive/html/bug-glibc/2002-11/msg00092.html If it is to be documented and not fixed, it should probably be documented in a central place for all boost. (This is a good idea regardless). I think it should be fixed, given that the main difference is using a static buffer vs a stack allocated buffer and that the current version does more work (damage?) than the reentrant version. Yitzhak Sapir

2 1

copy_if, composition, and proper predicate
by Michael Goldshteyn 08 Mar '05

08 Mar '05

Given: // Definitions class Element { public: const std::string &GetTag() const; }; typedef std::vector<Element> ElementContainer; // Now here is what is required ElementContainer elements; ... ElementContainer matchingElements; std::string matchingTag("abc"); copy_if(elements.begin(),elements.end(),back_inserter(matchingElements)),pred); -- What is pred? Assuming that iElements represents the iterator inside copy_if, pred should be something like: iElements->GetTag()==matchingTag I could go about this by creating a new function object class/struct, which takes matchingTag as its sole constructor argument and does the comparison inside operator(). But, I want to use in place composition using binders, etc... to create the pred, so as not to have to create a function object class/struct. The question is, "What piece of code should pred be?" // Almost does the right thing, but it's only *iElements==matchingTag, I need iElements->GetTag()==matchingTag bind_2nd(equal_to,matchingTag) This seems like a very common operation. How can I compose the predicate, in place to do this? If there are multiple solutions, I would like to hear them as well! Thanks, Michael

2 1

Archive stuck
by Gennadiy Rozental 08 Mar '05

08 Mar '05

Sorry I know I was given direct address. But I couldn't locate it for some reason. Gennadiy

1 1

Re: [boost] Re: What I Hate About How We Abstract System Dependence
by brangdon＠cix.compulink.co.uk 08 Mar '05

08 Mar '05

In-Reply-To: <422D79A6.4050502(a)aaronwl.com> aaronrabiddog51(a)aaronwl.com (Aaron W. LaFramboise) wrote (abridged): > > I have always thought that concrete implementations of portable > > libraries should supply users a way to get at the OS-specific data so > > they can use platform-specific facilities on them if neccessary. > [...] > It seems to me that, by doing this, we are throwing away so many > correctness guarantees. To me, this seems sort of like taking > shared_ptr, and making it implicitly convertable to a pointer. Surely it's more like taking shared_ptr and giving it an explicit get() function? You can break invariants by doing stuff like: delete p.get(); but people are unlikely to do that by accident. Access to the underlying raw pointer is essential for inter-operating with software which isn't smart-pointer aware. So it is with OS handles. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: What I Hate About How We Abstract System Dependence
by brangdon＠cix.compulink.co.uk 08 Mar '05

08 Mar '05

In-Reply-To: <loom.20050308T013051-569(a)post.gmane.org> belvis(a)pacbell.net (Bob Bell) wrote (abridged): > Another possibility is to provide another level of indirection. For > example, boost::thread can have an accessor which returns a > boost::platform_thread, which has the OS thread ID, plus member > functions which mimic OS operations not reflected in the portable > (boost::thread) API. The advantage of this approach is that > boost::platform_thread member functions may be able to preserve > invariants that otherwise might be broken if the user was allowed > to manipulate the underlying OS thread ID itself, and if the coverage > of the boost::platform_thread member functions is large enough, it > might not even be necessary to expose the OS thread ID at all. I don't think the coverage could never be large enough. We should always allow for 3rd parties which are not boost-aware, and which need to be passed low-level OS handles. -- Dave Harris, Nottingham, UK

1 0

[iostreams] names for non-blocking character properties
by Jonathan Turkanis 08 Mar '05

08 Mar '05

Hi All, Everybody likes naming questions, right? The thread "[iostreams] Major interface changes planned" discussed having the get() function return a type (basic_character, character or wcharacter) which can hold either a character, an EOF indication or an EAGAIN indication. My question is what I should call the functions which query the state of a basic_character. My first idea was to use bool good(character c) - returns true if c represents a character rather than EOF or EAGAIN bool eof(chacrater c) - returns true if c represent EOF bool fail(character c) - returns true if c represents EAGAIN. These functions have the same names as member functions of basic_ios. However, since fail() above doesn't mean exactly the same thing as basic_ios::fail(), I now think this is a bad idea. Here are the names I've thought of: good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry I also need names for the two functions called by implementations of get() to return characters representing EOF and EAGAIN. E.g., template<typename Source> character get(Source& src) { ... if ( ... ) return eof(); else return eagain(); } (They will actually return instances of types convertible to basic_character.) What do you think? Jonathan

3 7

[shmem] New Shmem snapshot ready in Boost Files section
by Ion Gaztañaga 08 Mar '05

08 Mar '05

Hello to all, I've just uploaded a new version of Shmem library (removed Boost from name because of the new naming policy) to Boost Files (http://groups.yahoo.com/group/boost/files/) which includes built html help files. Snapshot file: Shmem.2005-03-06.tar.bz2. Changes and features from last version: -> Name changes. -> Improved compatibility with unordered_map/set family. Soon we will be able to place unordered containers in shared memory. Thanks, Daniel. -> Templatized index types for named shared memory object allocator -> New private segregated storage STL allocator for shared memory. -> Bug fixes -> Improved documentation and code comments. For the next version I plan to improve code comments, documentation and tests. Please, if there is any comment or suggestion, let me know. Regards, /Ion

2 1

Is (void) still means ()? Is that syntax deprecated?
by Pavel Chikulaev 08 Mar '05

08 Mar '05

ISO/IEC 14882:1998(E) 8.3.5 (2) says: The parameter list (void) is equivalent to the empty parameter list. Is there any paper that shows that syntax (void) deprecated? I am asking about it because I'm trying to remove (void) syntax in Visual Studio's 2005 IDE Class View and Add Member Wizard. Is there any ideas how to remove it? P.S. As for me, It is really annoying.

1 0

[Boost.Regex] Not compiling without exceptions.
by larsbj＠gullik.net 08 Mar '05

08 Mar '05

In cpp_regex_traits.cpp line 76 there is a re-throw. This does not work when compiling without exceptions. I see that gcc have a #ifndef __EXCEPTIONS # define __throw_exception_again #else # define __throw_exception_again throw #endif for this case. Something similar should work for boost as well. To allow compiling I did this: --- ../../boost/boost/throw_exception.hpp 2004-08-05 17:24:43.000000000 +0200 +++ boost/throw_exception.hpp 2005-03-08 03:04:27.066704153 +0100 @@ -32,6 +32,8 @@ void throw_exception(std::exception const & e); // user defined +#define BOOST_THROW_EXCEPTION_AGAIN + #else template<class E> inline void throw_exception(E const & e) @@ -39,6 +41,8 @@ throw e; } +#define BOOST_THROW_EXCEPTION_AGAIN throw + #endif } // namespace boost -- Lgb

3 3

Incredible Logos
by John Maddock 08 Mar '05

08 Mar '05

As someone who hasn't paid that much attention to the logos during their development, I have to say going to vote was a revelation - there were so many exceptionally high quality logos to choose from - all I can say is there's some really talented people on this list and whatever the result I think we're going to end up with an excellent new logo. Well done everyone! John.

1 0

Re: What I Hate About How We Abstract System Dependence
by Chris Just 08 Mar '05

08 Mar '05

Rob Stewart wrote: > Another possibility is to provide another level of indirection. For > example, boost::thread can have an accessor which returns a > boost::platform_thread, which has the OS thread ID, plus member functions > which mimic OS operations not reflected in the portable (boost::thread) API. > The advantage of this approach is that boost::platform_thread member > functions may be able to preserve invariants that otherwise might be broken > if the user was allowed to manipulate the underlying OS thread ID itself, and > if the coverage of the boost::platform_thread member functions is large > enough, it might not even be necessary to expose the OS thread ID at all. This is exactly what I would like to see. Boost::thread and other classes should be platform neutral, but provide a method to get at the private handles so that people can extend the class for specific platforms on their own. Another thing I would REALLY like to see is better documentation. I'd love to use more Boost classes, but I don't have time to reverse engineer them to figure out how they work. Chris. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

2 1

My Thoughts on the Best Logos
by Rob Stewart 08 Mar '05

08 Mar '05

I decided to jump in with my ideas for the best logos and my comments on them. 1. 67 Simeon Nasilowski I liked this one because the checkerboard is abstract for several things: building blocks (Boost provides software building blocks), fitting the missing piece (Boost often provides just what you're missing), blended parts of C++ syntax (you can infer :: and }{, for example). I also liked that the checkerboard itself could be used as an icon, including in the address/location bar of the browser. What I don't like is the color scheme. I think a bluer scheme would be better. "C++ Libraries" could also be replaced with other tag lines like: - Setting the Standard - C++: The Next Generation (might be a copyright problem) - Your C++ 2. 83 Emil Kirichev I liked the color wheel, since it could be extracted as an icon and it suggests a never ending stream of libraries from Boost. I don't like the multiple colors; a simpler scheme would be better, I think. "C++ Library" should be plural, at the least, and could be replaced with numerous tag lines. 3. 49 Cristian Peraferrer Mayn? This logo looks really sharp and might have been my first choice, except for a couple of issues. I liked the coloring and the lettering. Since there is no accompanying graphic, it would be difficult to form an iconic version of this logo. The shading in the letters and the border requires a high number of colors; will it look as attactive with less color depth? 4. 21 Jonathan Turkanis I like the grayscale variant best, but the black works OK for lower color depths. There's too much gap between the "C" and "boost." It doesn't render well at low resolution, including as an icon. 5. 38 Simeon Nasilowski I like the "b" variant best. (I'm partial to the blue color palette, it seems.) The blocks can be used separately as an icon and there's always room to add a tag line (push "boost" up and put the tag line below as with #83). The foreground block could be adorned with a "C" yielding "C++," though that leaves the other, exposed surfaces with nothing. I don't know if that will look right or not. Adding a tag line would improve this one quite a bit. -- Rob Stewart stewart(a)sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

1 0

Re: [boost] thread safety in boost date time
by Iain Hanson 08 Mar '05

08 Mar '05

On Tue, 2005-03-08 at 06:20 -0700, Jeff Garland wrote: > On Tue, 8 Mar 2005 14:48:00 +0200, Peter Dimov wrote > > Well I don't think just calling the _r function is enough to ensure the thread > safety of this code. I believe I would have to insert a lock in the date-time > code to make this assurance. > Yes it is. the _r versions require a user supplied buffer. So each caller supplying there own buffer is what makes them re-entrant. /ikh

1 0

Re: [boost] Re: FSM Review
by Iain Hanson 08 Mar '05

08 Mar '05

On Mon, 2005-03-07 at 21:24 -0500, David Abrahams wrote: > "Iain K. Hanson" <ikh(a)hansons.demon.co.uk> writes: > > > On Mon, Mar 07, 2005 at 06:03:15PM -0500, David Abrahams wrote: > >> "Andreas Huber" <ahd6974-spamgroupstrap(a)yahoo.com> writes: > >> > > > > [snip] > > > >> > > >> > That depends on the functionality. I don't think it is possible if you > >> > want to provide support for orthogonal regions. > >> > >> Sorry, I don't really understand the concept. How are they different > >> from separate state machines? > > > > AFAICT nothing. State charts are always collapseable to state transition > > tables. > > This has something to do with STTs and State Charts? I'm lost. > Nothing else you say here helps clarify the concept of orthogonal > regions for me. No. Sorry, I should not have run the two together. orthogonal regions are also know as concurrent states. They are separate state machines running on separate threads. The other stuff was to give you an idea of what would be needed to support a state chart DSL and generator. /ikh

1 0

boost/operators.hpp remarks
by Sylvain Pion 08 Mar '05

08 Mar '05

Hi, I have been using boost/operators.hpp recently, and found it quite good at removing lines of code from my maintainance area :) I have some remarks about it : 1/ The mixed operators are only provided if you know the type in advance and it is fixed. For example, it is not possible for example to mix with a template family of types. E.g. let's say that My_type has to provide mixed operators with all types X<U>. This is not possible to do with the current library. Another related thing is how to express "I want My_type to mix with all integral types". Maybe there could be a version of the operators that uses enable_if and tr1::is_integral somehow, for this purpose ? Just a thought. 2/ I think it is "Euclidean Ring", not "Euclidian Ring" ("e" instead of "i"), hence the names for euclidian_ring_operators<T> and similar, are unfortunate. -- Sylvain

3 3

thread safety in boost date time
by Yitzhak Sapir 08 Mar '05

08 Mar '05

Boost date_time apparently has a thread safety problem in linux in that it calls localtime() in boost/date_time/time_clock.hpp and related functions rather than localtime_r() and related functions. This is even though BOOST_HAS_PTHREADS is defined by configure in user.hpp. Yitzhak Sapir

3 3

casp.hpp workaround and more
by Gennadiy Rozental 07 Mar '05

07 Mar '05

1. Shouldn't this header use workaround from config/suffix.hpp instead of BOOST_EXPLICIT_DEFAULT_TARGET? 2. Shouldn't this header be split by ..._cast? 3. Doesn't numeric_cast facility shouldn't be deprecated? Genandiy

4 23

RPC library
by Jarl Lindrud 07 Mar '05

07 Mar '05

Hi all, I've searched this list a bit and found a few mentions of rpc's (Remote Procedure Call), but nothing concrete. I've written a library for doing portable C++ RPC's, which can be downloaded at http://www.codeproject.com/threads/RMI_For_Cpp.asp Is there any interest in Boost for something like this, and if so in what directions do you all think it should be developed? Thanks! Jarl.

7 20

Re: [boost] Re: Logo Contest Current Tally
by JOAQUIN LOPEZ MU?Z 07 Mar '05

07 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> [...] > Well, now Joel and Jeff Garland have both told me by private mail that > there doesn't seem to be anything wrong with having a discussion about > what's worth voting for, and I am basically convinced. I think > certainaspects of the logo are more important than others and > should be > considered. But before I start blurting out any specifics, let's hear > from the group. Is there any reason we shouldn't talk about how to > choose? We do almost everything at boost by public consensus. Why > not this time? Well, I don't have any strong opinion about whether this poll should be kept in privacy or not, but certainly there is a difference between the contest and other activities: the former is a voting process, unlike all other decisions taken here (including reviews.) Joaquín M López Muñoz Telefónica, Investigacion y Desarrollo

1 0

Re: [boost] Re: Logo Contest Current Tally
by Iain Hanson 07 Mar '05

07 Mar '05

On Mon, 2005-03-07 at 12:48 -0500, David Abrahams wrote: > christopher diggins <cdiggins(a)videotron.ca> writes: > [snip] > Well, now Joel and Jeff Garland have both told me by private mail that > there doesn't seem to be anything wrong with having a discussion about > what's worth voting for, and I am basically convinced. I think certain > aspects of the logo are more important than others and should be > considered. But before I start blurting out any specifics, let's hear > from the group. Is there any reason we shouldn't talk about how to > choose? We do almost everything at boost by public consensus. Why > not this time? > I think it would be a good thing. If people are influenced by it will be no different than the review process. I also have no problem with the running tally. /ikh

1 0

FSM Review
by Peter Petrov 07 Mar '05

07 Mar '05

I have used and watched closely this library for more than a year, since its early versions. Initially, we needed a good modern state machine framework for a project at the company I work for. After evaluating the possibilities, we decided to take the risk and go with Andreas' FSM, despite its early-alpha state at the time. Now, one year later, that choice has proved to be correct. We have used FSM in one more project and are planning to use it in future projects too. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? The documentation is very adequate. I was able to quickly understand how to use the basic features of the library, and then proceed to the advanced ones. At that time I had experience with different kinds of state machines, but primarily SDL-specified. FSM's documentation was my first introduction to UML state charts, and did the job well. The tutorial is excellent. The FAQ and Rationale sections give important answers to questions which are likely to arise. There is also an extensive Reference section, which I needed very rarely. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? To me, the design is good and follows naturally from the objectives of the library. It imposes some restrictions, although they can be overcome if necessary (for me it has not been necessary). For example, machines don't recognize polymorphic events, therefore they cannot "forward" unknown events to another machine. This can be circumvented by using a "wrapper" event around such events, which works, but only with asynchronous machines. Another example is the way that state machines are inherited - it's not very flexible and only allows altering how a state machine reacts to an already recognized event. One cannot add support for new events, except using again the "wrapper event" trick. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? The name (boost::fsm, Boost.FSM) is fine for me. Regarding separating the library into two parts, I prefer it being separated, since the Worker part is useful by itself. * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? It's as obscure as its complexity requires. At the same time it is stable and bug-free, which is proved by extensive bulk-testing in our labs. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it usable for embedded systems? Is the documentation clear on performance tradeoffs? The documentation is definitely clear on performance tradeoffs, and it's up to the potential user to take an informed decision. One tradeoff is that dispatch time is linear to the number of nested states. In my experience this is not a problem, since there are rarely more than two nested states, and I have never seen more than three. A possible problem is that states are constructed using operator new(). The documentation clearly states that, and the library allows overcoming the issue by specifying a custom allocator for the state machine, as well as writing custom operator new()'s for all state classes. I personally am against the second requirement and think that it complicates things too much. Specifying a custom allocator for the state machine should be enough. (this is mentioned in the documentation, in the Rationale section under "Memory management customization") * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? The greatest distinction of code written using the FSM library is its manageability. It's very easy to write and subsequently evolve state machines and most common mistakes are caught at compilation time. When state machines are involved, using FSM is definitely a great improvement over using a primitive framework, or not using a framework at all (the notorious switch/case idiom). Especially if the library's advanced features are used. * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? Used with MSVC++ 7.1 and GCC 3.x. Currently without problems. In the early versions there were some minor issues which Andreas has addressed quickly. Regarding older compilers, I don't think they should be supported by this library. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In-depth study, as well as real-world usage. * Are you knowledgeable about the problem domain? To a good extent. I have developed two different state machine frameworks, although both of them were significantly lower level than FSM. I have also worked extensively with various kinds of state machines, mainly protocol-related and in telecom applications. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. Definitely.

2 1

[interfaces] Hand written interfaces
by Jonathan Turkanis 07 Mar '05

07 Mar '05

Hi All, I'm working on ways to make the Boost Interfaces library easier to use. This involves making interface definitions compile faster and making them easier to read. Unfortunately, these are somewhat conflicting goals: really messy-looking interface definitions may compile much faster than simple ones. I'm working on four approaches to interface definitions; I plan to implement them all and then compare them. Right now I'm looking for feedback on number 4: 1. The current IDL, possibly slightly modified, in which an interface definition consists of a sequence of macro invocation 2. A modified IDL in which an interface definition consists of a single invocation; this increases the amount of preprocessor metaprogramming but decreases the amount of template metaprogramming 3. The pseudocode IDL, together with an IDL compiler which translates pseudocode definitions into C++ class definitions requiring virtually no metaprogramming. 4. Hand written interfaces, requiring virtually no metaprogramming. The point of allowing hand-written interfaces is to decrease compile times. There's no question that writing interfaces by handle will be the most difficult of the above four options. Still, writing interfaces by hand has to be reasonably straightforward or no one will ever do it. So here's my question. Consider the interface: interface IBar { void foo(const char*); int foo(int, int); }; Is the following definition of IBar so complex that it would be pointless to offer it as an alternative? template< typename Derived, typename Base, typename Flags > struct ibar_impl { struct type : Base { struct interface_metadata : metadata_base<Derived, Base, Flags> { const char* names = { "foo", "foo" }; typedef mpl::vector< void(const char*), int(int, int) > signatures; }; void foo(const char* name) { return invoker<interface_metadata, 1>::execute(this, name); } int foo(int n, int m) { return invoker<interface_metadata, 2>::execute(this, int, int); } }; }; typedef interface< ibar_impl<_, _, _> > IBar; Best Regards, Jonathan

4 8

RE: [boost] Re: review of proposed fsm library
by Dave Gomboc 07 Mar '05

07 Mar '05

> > Otherwise you would be able to mix both synchronous and > asynchronous > > states in one machine, which doesn't make sense. > > While tangential to my original point about naturally > recursive structures, I'll take time out to disagree here > too. It _can_ make sense to combine async and sync behaviour > in different parts of a state machine when one is modeling > electrical circuits, e.g. in certain regions of the circuit > one may know that the behaviour is sync and not want to spend > extra CPU by going through all the async motions. I will quickly add that this issue (combining async and sync fsms) will occur whenever one has prior components that one wishes to assemble together, where some are async and some are sync. Dave

1 0

Re: [boost] Re: review of proposed fsm library
by Dave Gomboc 07 Mar '05

07 Mar '05

> > The distinction made between state and state_machine, > which I > consider to be unfortunate, was not justified in > the rationale... > > There is at least one good reason - the library supports both > synchronous and asynchronous state machines, which are > essentially different beasts and are operated quite > differently. No such distinction exists for states, therefore > they shouldn't be treated the same way as state machines. However, asynchronous_state_machine is separated from both state_machine and state. Ergo, the reason must lie elsewhere. I didn't delve deeply into the library's support for asynchronicity, but I did consider it odd and amusing that at the level of hardware circuitry, asynchronous behaviour is the default, and work is done to get synchronous behaviour by adding latches and a clock, but that for fsm (and many, many other software components rather higher-level than a J-K flip-flop) the opposite was true. I do understand it, but I am not convinced that in this case it was the correct decision. Unforunately, I have to leave for work now. :-) > Otherwise you would be able to mix both synchronous and > asynchronous states in one machine, which doesn't make sense. While tangential to my original point about naturally recursive structures, I'll take time out to disagree here too. It _can_ make sense to combine async and sync behaviour in different parts of a state machine when one is modeling electrical circuits, e.g. in certain regions of the circuit one may know that the behaviour is sync and not want to spend extra CPU by going through all the async motions. Dave

1 0

Re: [boost] Re: RPC library
by Iain Hanson 07 Mar '05

07 Mar '05

On Sun, 2005-03-06 at 22:59 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > To sum up then, your position is that: > > 1) CORBA is the be-all and end-all of distributed programming. > No. Its just the best that we have available. > 2) Anything not projected to need CORBA-style scaleability is just a "toy" and > not worthy of library support. > Probably. But the problem is that people build quick and dirty apps that grow like Topsy. Its the danger of this that make me against non scalable solutions. > > I guess you don't find much need for networking at all in Boost? At least not > beyond lowlevel socket API wrappers and assorted utilites that might be useful > for something like realtime socket apps. Anything beyond that can, and should, > be done with CORBA, regardless of scale and scope. > Doug Schmidt certainly tends to argue in this direction. However, given that CORBA is not ubiquitous and is not ever likely to be then there is always going to be a need for sockets. /ikh

1 0

Help need reed related to libboost_filesystem.lib
by Thota, Vimal 07 Mar '05

07 Mar '05

Dear friends, I am using the boost libraries for my project. When I am compiling the (libboost_filesystem.lib) with my project files libraries which is available in the ibs\filesystem\build\bin\libboost_filesystem.lib\vc7.1\release\runtime-l ink-dynamic , I am facing with the Linking issues which I have listed down. Are you people able to guess where I have gone wrong. Thanks, Vimal Thota Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::~dir_it(void)" (??1dir_it@filesystem@boost@@QAE@XZ) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0dir_it@filesystem@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@@Z) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(void)" (??0dir_it@filesystem@boost@@QAE@XZ) Disk Manager error LNK2001: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_directory>::operator bool(void)const " (??B?$get@Uis_directory@filesystem@boost@@@filesystem@boost@@QBE_NXZ) Disk Manager error LNK2001: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator++(void)" (??Edir_it@filesystem@boost@@QAEAAV012@XZ) Disk Manager error LNK2001: unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::filesystem::dir_it::operator*(void)const " (??Ddir_it@filesystem@boost@@QBE?AV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@XZ) Disk Manager error LNK2001: unresolved external symbol ___argc Disk Manager error LNK2001: unresolved external symbol ___argv Disk Manager error LNK2001: unresolved external symbol __mbctype Disk Manager error LNK2001: unresolved external symbol __mbctype Disk Manager error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in msvcprtd.lib(newop_s.obj) Disk Manager error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in msvcprtd.lib(newaop_s.obj) Disk Manager error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in MSVCRTD.lib(MSVCR71D.dll) Disk Manager error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in MSVCRTD.lib(MSVCR71D.dll) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::~dir_it(void)" (??1dir_it@filesystem@boost@@QAE@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0dir_it@filesystem@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::dir_it::dir_it(void)" (??0dir_it@filesystem@boost@@QAE@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::ctime>::operator long const *(void)const " (??B?$get@Uctime@filesystem@boost@@@filesystem@boost@@QBEPBJXZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_archive>::operator bool(void)const " (??B?$get@Uis_archive@filesystem@boost@@@filesystem@boost@@QBE_NXZ) referenced in function "public: bool __thiscall DirectoryWatcher::next_archived(void)const " (?next_archived@DirectoryWatcher@@QBE_NXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::is_directory>::operator bool(void)const " (??B?$get@Uis_directory@filesystem@boost@@@filesystem@boost@@QBE_NXZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall boost::filesystem::get<struct boost::filesystem::mtime>::operator long const *(void)const " (??B?$get@Umtime@filesystem@boost@@@filesystem@boost@@QBEPBJXZ) referenced in function "public: long __thiscall DirectoryWatcher::next_age(void)const " (?next_age@DirectoryWatcher@@QBEJXZ) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall DMWorkflowInterface::~DMWorkflowInterface(void)" (??1DMWorkflowInterface@@QAE@XZ) referenced in function "public: void * __thiscall DMWorkflowInterface::`scalar deleting destructor'(unsigned int)" (??_GDMWorkflowInterface@@QAEPAXI@Z) Disk Manager error LNK2019: unresolved external symbol "public: __thiscall DMWorkflowInterface::DMWorkflowInterface(void)" (??0DMWorkflowInterface@@QAE@XZ) referenced in function "public: virtual void __thiscall DiskManagerService::MainThread(void)" (?MainThread@DiskManagerService@@UAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: bool __thiscall boost::filesystem::dir_it::operator!=(class boost::filesystem::dir_it const &)const " (??9dir_it@filesystem@boost@@QBE_NABV012@@Z) referenced in function "private: void __thiscall DiskManagerService::check_watchers(class std::map<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class DirectoryWatcher *,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class DirectoryWatcher *> > > &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?check_watchers@DiskManagerService@@AAEXAAV?$map@V?$basic_string@DU?$ch ar_traits@D@std@@V?$allocator@D@2@@std@@PAVDirectoryWatcher@@U?$less@V?$ basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@V?$allocat or@U?$pair@$$CBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@ std@@PAVDirectoryWatcher@@@std@@@2@@std@@ABV?$basic_string@DU?$char_trai ts@D@std@@V?$allocator@D@2@@3@@Z) Disk Manager error LNK2019: unresolved external symbol "public: bool __thiscall boost::filesystem::dir_it::operator==(class boost::filesystem::dir_it const &)const " (??8dir_it@filesystem@boost@@QBE_NABV012@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator++(void)" (??Edir_it@filesystem@boost@@QAEAAV012@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class boost::filesystem::dir_it & __thiscall boost::filesystem::dir_it::operator=(class boost::filesystem::dir_it const &)" (??4dir_it@filesystem@boost@@QAEAAV012@ABV012@@Z) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol "public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall boost::filesystem::dir_it::operator*(void)const " (??Ddir_it@filesystem@boost@@QBE?AV?$basic_string@DU?$char_traits@D@std@ @V?$allocator@D@2@@std@@XZ) referenced in function "private: void __thiscall DirectoryWatcher::find_next(void)" (?find_next@DirectoryWatcher@@AAEXXZ) Disk Manager error LNK2019: unresolved external symbol __mbctype referenced in function "protected: long __thiscall CEditView::OnFindReplaceCmd(unsigned int,long)" (?OnFindReplaceCmd@CEditView@@IAEJIJ@Z) Disk Manager fatal error LNK1120: 17 unresolved externals Disk Manager warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

[optional]output
by Gennadiy Rozental 07 Mar '05

07 Mar '05

Hi, Maybe it's something that I missed, but why optional doesn't define output operator something like this: template<typename T> inline std::ostream& operator<<( std::ostream& ostr, optional<T> const& v ) { if( v ) ostr << *v; return ostr; } Gennadiy

1 0

Boost Logo Contest Request for independent tally
by Joel de Guzman 07 Mar '05

07 Mar '05

Hi, Jonathan noted a minor error in the recent (initial) tally where his entry got listed twice. In the interest of fairness... I would like to request for help. If anyone is interested in doing an independent tally, I'd gladly provide him/her with access to the submitted votes. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

2 2

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by Jonathan Turkanis 07 Mar '05

07 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

3 9

Logo Contest: Send In Your votes!
by Joel de Guzman 07 Mar '05

07 Mar '05

Hi Y'all, Acceptance of logo entries is officially over. I waited more than 24 hours after the March 1 deadline to account for the time zones. For my convenience, I find it best to simply collect the votes by email. For this purpose, I setup a mail account at address: boost.logo.contest(a)gmail.com where you can send your votes to. For transparency, I shared the password with the Boost Moderators, so they can check the status anytime. Please be reminded that voting shall be based on Instant Runoff Voting (http://www.fairvote.org/irv/whatis2.htm) meaning that each individual voter shall choose 5 favorites, in order of preference. Please send in your votes in this format: 1. 1st choice: Entry number (variant), Submitter 2. 2nd choice: Entry number (variant), Submitter 3. 3rd choice: Entry number (variant), Submitter 4. 4th choice: Entry number (variant), Submitter 5. 5th choice: Entry number (variant), Submitter ***where variant, designated by a letter, is optional. Example: 1. 225, John Doe 2. 336a, Jane Doe 3. 751, Apple Pie 4. 101b, Dorothy Rainbow 5. 855, Kim Possible I shall be collecting votes and progressively posting the results in the boost web site. The competition will close on March 15, 2005 and the winning entry will be announced soon thereafter. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

5 12

RE: [boost] high_resolution_timer \ timer feature requests forBoost.Timer
by Brian Braatz 07 Mar '05

07 Mar '05

(sorry - mail client weirdness on the last post- I have fixed the doublespacing)(here is the mail again) ********************************************* First off- note that Timer can take a start time on the ctor: class timer { public: timer() { _start_time = std::clock(); } // postcondition: elapsed()==0 (snip) high_resolution_timer does not however: class high_resolution_timer { public: // ctor high_resolution_timer() { start_time.QuadPart = 0; frequency.QuadPart = 0; if (!QueryPerformanceFrequency(&frequency)) throw std::runtime_error("Couldn't acquire frequency"); restart(); } (snip) MY PROBLEM: I need to feed the timer the START time (or get FROM it the start time would be preferred) The reason I need this is because for logging purposes (working with the Profiler from Christopher Diggins) I need to log the start and stop times, and I need it to (for internal cross reference) be the same number for multiple purposes. MY REQUESTS: Easy request: high_resolution_timer is changed to have the same type of ctor as timer does May Start a discussion request: That something like a starttime() method is provided for both classes Medium request- That both classes do a typedef for the type returned by the starttime method i.e. instead of class high_resolution_timer { public: (snip) private: timer t; // backup in case of QueryPerformanceCounter() bug LARGE_INTEGER start_time; LARGE_INTEGER frequency; }; You have instead: class high_resolution_timer { public: (snip) typedef LARGE_INTEGER TIME_TYPE; private: timer t; // backup in case of QueryPerformanceCounter() bug TIME_TYPE start_time; TIME_TYPE frequency; }; (for both high_resolution_timer and timer) There you go, those are my requests. Now I will sit here quietly and hope there is a Santa Claus.... (grin)

3 2

RE: [boost] Re: high_resolution_timer \ timer feature requestsforBoost.Timer
by Brian Braatz 06 Mar '05

06 Mar '05

The code I am using was originally developed by Christopher Diggins. His code allows for use of boost.timer or the high_resolution_timer. I am currently using the high_resolution timer. THANK YOU for the suggestion of using the microsec_time_clock.hpp. I did not know that existed, do you know how does this compare to the high_resolution timer? I need to stick to a base release version of boost for production reasons, do you think this other timer will work inside 1.32? Thank you very much for your thoughts, I would not have noticed the microsec if you had not pointed it out to me. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Caleb Epstein > Sent: Friday, March 04, 2005 8:32 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: high_resolution_timer \ timer feature > requestsforBoost.Timer > > On Fri, 4 Mar 2005 10:42:16 -0700, Brian Braatz <brianb(a)rmtg.com> wrote: > > > But the Profile LOG (like a trace of what happened) looks like this > > DEPTH NAME TIME > > 0 FuncA 2 Seconds > > 1 FuncB 1 Second > > > > Does that answer your question, or am I missing something? > > Just a subtle point, but the boost::timer class returns CPU time used > not elapsed wall-clock time and would return results of ~0.0 for a > function that just sleep'd for a second or two. > > If what you're looking for is a high-resolution clock, try > <boost/date_time/microsec_time_clock.hpp> (at least in the latest > CVS). If you want performance or profiling information, use > boost::timer. > > > -- > Caleb Epstein > caleb dot epstein at gmail dot com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Integrating Boost Documentation with Visual Studio IDE.
by Pavel Chikulaev 06 Mar '05

06 Mar '05

Hi all, I don't know how many of boosters use VC, but I think intergrating boost documentation with visual studio IDE will help VC developers a lot. Key feature is context help, for example pressing F1 when cursor is on "BOOST_PP_REPEAT" token will instantly open help on BOOST_PP_REPEAT instead of opening boost.org(or saved page), then documentation, then preprocessor, the reference, then scrolling a lot in left frame for PP_REPEAT. Right know I don't know how to do it, but I'll try to find the easiest way to do it. P.S. I almost have no exprerience with other IDEs, but I think it is also possible to integrate boost documentation with them too.

2 1

Wanted : Modified Boost Jamfiles for Mac OS X
by Tommy Nordgren 06 Mar '05

06 Mar '05

Could someone please mail me an archive with modified Jamfiles, that allows the Boost 1.32 libraries to be built with Mac OS X 10.3.8, on a 512 MB machine. Currently the build stalls when compiling a file called xml_parser.cpp, exhausting virtual memory. As an alternative, can someone tell me how to exclude builds that uses the Spirit Framework. "Home is not where you are born, but where your heart finds peace" - Tommy Nordgren, "The dying old crone"

4 3

FSM review
by Jeff Garland 06 Mar '05

06 Mar '05

I'll start my review with the conclusion: I recommend fsm be accepted into Boost -- thanks to Andreas for his excellent contribution. FSMs apply to a broad range of software products and the proposed library would simplify the implementation of many of them. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? Overall I think the documentation is good, although I think the tutorial code be improved slightly by carefully illustrating the 'boilerplate' part from where the user would add code either to a machine or to a state and the design tradeoffs that would drive one to this approach (we had some discussion of this earlier and it might be better in the FAQ then in the tutorial). * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? Overall the library is well thought out and supports a wide range of essential features for building fsms. * What is your evaluation of the implementation? I spent a few minutes browsing the implementation. In general the code is written clearly and understandably -- even though I couldn't possibly understand the full context of the code or truly evaulate the implementation. There is also a large number of tests already written which should help with porting / regression testing. Overall the implementation appears to be up to usual boost standards. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? No opinion on this except that there is good documentation of the performance implications of using the library. * What is your evaluation of the potential usefulness of the library? *Can you compare this FSM to other implementations? Most other FSM implementations are code generators of one sort or another. For example: <http://smc.sourceforge.net>. Being a pure library (and a header library as well) makes the current proposal very attractive. No new tools to required to take advantage of the capabilities. * Did you try to use the library? With what compiler? Did you have any problems? Yes - gcc 3.3.1 under dev-c++. No problems. I modified the tutorial examples to try and understand what a user would need to learn to use the library. *Do you have tips for better support of older compilers? What are possible portability problems? I think Andreas should ignore older compilers. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours. I also looked at the library about a year ago and followed list discussions over the last couple years. * Are you knowledgeable about the problem domain? I'm quite famaliar with FSM for software design having first studied them in college over 20 years ago. I've also worked on projects that use state machine compilers. *The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? 1. Library name -- Obviously boost::fsm is not for everyone.... I think the library name is fine. 2. Two libraries in one: The library consists of two parts that could easily be separated... I'd leave the library alone for now. More experience will show whether it makes sense to split it. 3. Exception handling support: Several people have rightly pointed out that the rationale for the exception handling support is too thin. The rationale seems good enough to me for now. A more advanced paper would be nice, but doesn't seem essential to using the library. 4. On some compilers (e.g. gcc), the asynchronous part of the library and most of the tests currently cannot be compiled with RTTI turned off. This isn't a problem in my view as RTTI is a feature of C++. While I acknowledge that there are a group of folks that want to turn it off for embedded work, I think if they are that concerned about performance they probably won't use fsm anyway. So the bottom line is I don't see that this is a problem. Jeff

2 1

[serialization] flush ?
by troy d. straszheim 06 Mar '05

06 Mar '05

Here's a use case that has been discussed before, but to which I couldn't seem to find any solid resolution the list archives: class A; some_oarchive oa; void mutate(shared_ptr<A>& aptr_) { aptr_ = shared_ptr<A>(new A); }; shared_ptr<A> aptr; for (int i=0; i<LARGE_NUMBER; i++) { mutate(aptr); oa << aptr; } The problem is that your oarchive ends up with somewhere between two and LARGE_NUMBER distinct A's in it. Usually two. Presumably the "two" is because in this simple example only A's are getting allocated and deallocated, and therefore there are often free A-sized blocks conveniently laying around for reuse. aptr gets assigned A's at two different alternating addresses. If it was just a plain A, you could turn off tracking by not serializing through a pointer. You'd then get the right number of A's in your archive. But if elsewhere you want to serialize A through a pointer you can't do that just for this call to operator<<(). Also you don't have a good way to see if A actually is serialized via pointer elsewhere or not. (My use case is one where lots of inexperienced programmers are modifying the data structures contained in A, and they will surely screw up if the rules are more complicated than "use BOOST_CLASS_EXPORT in your header file, and never use bald pointers, always use shared_ptr".) I looked through the archives a bunch and didn't come across anything conclusive. It seemed that some thought this kind of use case was pathological, but I'm not sure why. Of course, I'm not all that experienced with serialization. What I'd like to be able to do is to tell the archive, "The previous calls to operator<<() represent a 'snapshot' of the state of some group of objects, and now I want you to forget about existent objects because I am going to rearrange them all. Continue to track object types, but forget about the addresses." I realize that this creates the possiblity for memory leaks, but if the serialization is done through one toplevel call to operator<< on a shared_ptr whose pointee contains pointers to a whole universe of home-cooked pointer spaghetti, I don't see a better way to do this, and I don't see how to clearly express what I intend via the export and tracking macro mechanisms. You can't close and reopen the archive in the top loop, you get duplicate headers. The list archives mention the use case of serializing the state of some memory pool that is very likely to get reused: I think the little example above is probably the simplest case of this. So without asking for a sanity-check, I implemented basic_oarchive::flush(), and some tests. The changes to basic_oarchive and basic_oarchive_impl are very small. basic_oarchive has an internal object_set, which tracks object_ids and addresses. I add a num_flushed_objects member, and flush() clears out the set and adds the number of objects flushed to this counter. New tracked objects are assigned object_ids starting at num_flushed_objects + object_set.size(). In this way the class_id's are reused post-flush, but object id's are not. The interface is simply this: class A; some_oarchive oa; void mutate(shared_ptr<A>& aptr_) { aptr_ = shared_ptr<A>(new A); }; shared_ptr<A> aptr; for (int i=0; i<LARGE_NUMBER; i++) { mutate(aptr); oa << aptr; oa.flush(); } No modifications are required to the iarchive, but the user code of course has to be written in such a way that objects aren't leaked. though "oa << archive::endl;" would be a cute way to flush, too. Dunno. Is this unnecessary because I'm missing something obvious? At any rate the modified files and two tests are attached. All tests pass with this change... troy d. straszheim /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // test_flush_simple.cpp // // copyright (c) 2005 // troy d. straszheim <troy(a)resophonic.com> // http://www.resophonic.com // // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // should pass compilation and execution // test verifies that basic_oarchive::flush() "resets" all pointers to objects #include <iostream> #include <fstream> #include <cstdio> // remove #include <boost/config.hpp> #if defined(BOOST_NO_STDC_NAMESPACE) namespace std{ using ::remove; } #endif #include <boost/archive/archive_exception.hpp> #include "test_tools.hpp" #include <boost/preprocessor/stringize.hpp> #include BOOST_PP_STRINGIZE(BOOST_ARCHIVE_TEST) #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> struct A { unsigned i; template <class Archive> void serialize(Archive &ar, unsigned) { ar & BOOST_SERIALIZATION_NVP(i); } static std::size_t num_objects_; public: virtual ~A(){ num_objects_--; } A() { num_objects_++; } static std::size_t num_objects() { return num_objects_; } }; std::size_t A::num_objects_ = 0; const unsigned NUMOBJS = 4; void do_save(const char *testfile) { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); oa.flush(); // be sure you can flush an empty archive A a; for (unsigned int i=0; i<NUMOBJS; i++) { a.i = i; oa << BOOST_SERIALIZATION_NVP(a); oa.flush(); BOOST_CHECK(A::num_objects() == 1); } // do some more flushes for the sake of thoroughness; oa.flush(); oa.flush(); oa.flush(); A* ap = &a; for (unsigned int i=0; i<NUMOBJS; i++) { ap->i = i; oa << BOOST_SERIALIZATION_NVP(ap); oa.flush(); BOOST_CHECK(A::num_objects() == 1); } oa.flush(); oa.flush(); oa.flush(); } // save exported polymorphic class void do_load(const char *testfile) { test_istream is(testfile, TEST_STREAM_FLAGS); test_iarchive ia(is); { A a; for (unsigned int i=0; i<NUMOBJS; i++) { ia >> BOOST_SERIALIZATION_NVP(a); BOOST_CHECK(a.i == i); BOOST_CHECK(A::num_objects() == 1); } } // a goes out of scope: no objects BOOST_CHECK(A::num_objects() == 0); A* ap; for (unsigned int i=0; i<NUMOBJS; i++) { ia >> BOOST_SERIALIZATION_NVP(ap); std::cout << "numobjs=" << A::num_objects() << std::endl; BOOST_CHECK(ap->i == i); BOOST_CHECK(A::num_objects() == (i+1)); // we leak 'em on purpose, we need to count em. } } int test_main( int /* argc */, char* /* argv */[] ) { const char * testfile = boost::archive::tmpnam(NULL); BOOST_REQUIRE(NULL != testfile); do_save(testfile); do_load(testfile); std::remove(testfile); return EXIT_SUCCESS; } // EOF /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // test_flush.cpp // // copyright (c) 2005 // troy d. straszheim <troy(a)resophonic.com> // http://www.resophonic.com // // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // should pass compilation and execution // test verifies that basic_oarchive::flush() "resets" all pointers to objects #include <iostream> #include <fstream> #include <cstdio> // remove #include <boost/config.hpp> #if defined(BOOST_NO_STDC_NAMESPACE) namespace std{ using ::remove; } #endif #include <boost/archive/archive_exception.hpp> #include "test_tools.hpp" #include <boost/preprocessor/stringize.hpp> #include BOOST_PP_STRINGIZE(BOOST_ARCHIVE_TEST) #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> class polymorphic_base { friend class boost::serialization::access; template<class Archive> void serialize(Archive & /* ar */, const unsigned int /* file_version */){ } static std::size_t num_objects_; public: virtual ~polymorphic_base(){ num_objects_--; } polymorphic_base() { num_objects_++; } static std::size_t num_objects() { return num_objects_; } }; std::size_t polymorphic_base::num_objects_ = 0; //BOOST_IS_ABSTRACT(polymorphic_base) class polymorphic_derived1 : public polymorphic_base { friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); } public: virtual ~polymorphic_derived1(){} }; BOOST_CLASS_EXPORT(polymorphic_derived1) class polymorphic_derived2 : public polymorphic_base { friend class boost::serialization::access; template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); } public: virtual ~polymorphic_derived2(){} }; BOOST_CLASS_EXPORT(polymorphic_derived2) // save exported polymorphic class void save_exported(const char *testfile) { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa(os); polymorphic_base *rb1 = new polymorphic_derived1; polymorphic_base *rb2a = new polymorphic_derived2; polymorphic_base *rb2b = new polymorphic_derived2; oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb2a); oa << BOOST_SERIALIZATION_NVP(rb2b); BOOST_CHECK(polymorphic_base::num_objects()==3); oa.flush(); oa << BOOST_SERIALIZATION_NVP(rb2b); oa << BOOST_SERIALIZATION_NVP(rb2a); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb1); BOOST_CHECK(polymorphic_base::num_objects()==3); oa.flush(); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb1); oa << BOOST_SERIALIZATION_NVP(rb2a); oa << BOOST_SERIALIZATION_NVP(rb2b); BOOST_CHECK(polymorphic_base::num_objects()==3); oa.flush(); delete rb1; delete rb2a; delete rb2b; BOOST_CHECK(polymorphic_base::num_objects()==0); } #define RETRIEVE_AND_CHECK(ARCHIVE, PTR, TYPE, N) \ ARCHIVE >> BOOST_SERIALIZATION_NVP(PTR); \ BOOST_CHECK_MESSAGE( \ boost::serialization::type_info_implementation<TYPE> \ ::type::get_instance() \ == boost::serialization::type_info_implementation<polymorphic_base> \ ::type::get_derived_extended_type_info(*PTR), \ "restored pointer " BOOST_PP_STRINGIZE(PTR) " not of correct type" ); \ BOOST_CHECK(polymorphic_base::num_objects()==N); // save exported polymorphic class void load_exported(const char *testfile) { test_istream is(testfile, TEST_STREAM_FLAGS); test_iarchive ia(is); polymorphic_base *rb1a = NULL, *rb1b = NULL; polymorphic_base *rb2a = NULL, *rb2b = NULL; RETRIEVE_AND_CHECK(ia, rb1a, polymorphic_derived1, 1); RETRIEVE_AND_CHECK(ia, rb1b, polymorphic_derived1, 1); RETRIEVE_AND_CHECK(ia, rb2a, polymorphic_derived2, 2); RETRIEVE_AND_CHECK(ia, rb2b, polymorphic_derived2, 3); RETRIEVE_AND_CHECK(ia, rb2b, polymorphic_derived2, 4); RETRIEVE_AND_CHECK(ia, rb2a, polymorphic_derived2, 5); RETRIEVE_AND_CHECK(ia, rb1a, polymorphic_derived1, 6); RETRIEVE_AND_CHECK(ia, rb1b, polymorphic_derived1, 6); RETRIEVE_AND_CHECK(ia, rb1a, polymorphic_derived1, 7); RETRIEVE_AND_CHECK(ia, rb1b, polymorphic_derived1, 7); RETRIEVE_AND_CHECK(ia, rb2a, polymorphic_derived2, 8); RETRIEVE_AND_CHECK(ia, rb2b, polymorphic_derived2, 9); } int test_main( int /* argc */, char* /* argv */[] ) { const char * testfile = boost::archive::tmpnam(NULL); BOOST_REQUIRE(NULL != testfile); save_exported(testfile); load_exported(testfile); std::remove(testfile); return EXIT_SUCCESS; } // EOF /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // basic_oarchive.cpp: // (C) Copyright 2002 Robert Ramey - http://www.rrsd.com . // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // See http://www.boost.org for updates, documentation, and revision history. #include <boost/config.hpp> // msvc 6.0 needs this for warning suppression #include <cassert> #include <set> #include <boost/limits.hpp> #include <boost/state_saver.hpp> #include <boost/throw_exception.hpp> // including this here to work around an ICC in intel 7.0 // normally this would be part of basic_oarchive.hpp below. #define BOOST_ARCHIVE #include <boost/archive/basic_archive.hpp> #include <boost/archive/detail/basic_oserializer.hpp> #include <boost/archive/detail/basic_pointer_oserializer.hpp> #include <boost/archive/detail/basic_oarchive.hpp> #include <boost/archive/archive_exception.hpp> #ifdef BOOST_MSVC # pragma warning(push) # pragma warning(disable : 4251 4231 4660 4275) #endif using namespace boost::serialization; namespace boost { namespace serialization { class extended_type_info; } namespace archive { namespace detail { class basic_oserializer; class basic_pointer_oserializer; class basic_oarchive_impl { friend class basic_oarchive; ////////////////////////////////////////////////////////////////////// // information about each serialized object saved // keyed on address, class_id struct aobject { const void * address; class_id_type class_id; object_id_type object_id; bool operator<(const aobject &rhs) const { assert(NULL != address); assert(NULL != rhs.address); if( address < rhs.address ) return true; if( address > rhs.address ) return false; return class_id < rhs.class_id; } aobject & operator=(const aobject & rhs) { address = rhs.address; class_id = rhs.class_id; object_id = rhs.object_id; return *this; } aobject( const void *a, class_id_type class_id_, object_id_type object_id_ ) : address(a), class_id(class_id_), object_id(object_id_) {} aobject() : address(NULL){} }; // keyed on class_id, address typedef std::set<aobject> object_set_type; object_set_type object_set; std::size_t num_flushed_objects; ////////////////////////////////////////////////////////////////////// // information about each serialized class saved // keyed on type_info struct cobject_type { const basic_oserializer * bos_ptr; const class_id_type class_id; bool initialized; cobject_type( std::size_t class_id_, const basic_oserializer & bos_ ) : bos_ptr(& bos_), class_id(class_id_), initialized(false) {} cobject_type(const basic_oserializer & bos_) : bos_ptr(& bos_) {} cobject_type( const cobject_type & rhs ) : bos_ptr(rhs.bos_ptr), class_id(rhs.class_id), initialized(rhs.initialized) {} // the following cannot be defined because of the const // member. This will generate a link error if an attempt // is made to assign. This should never be necessary // use this only for lookup argument cobject_type & operator=(const cobject_type &rhs); bool operator<(const cobject_type &rhs) const { return *bos_ptr < *(rhs.bos_ptr); } }; // keyed on type_info typedef std::set<cobject_type> cobject_info_set_type; cobject_info_set_type cobject_info_set; // list of objects initially stored as pointers - used to detect errors // keyed on object id std::set<object_id_type> stored_pointers; // address of the most recent object serialized as a poiner // whose data itself is now pending serialization const void * pending_object; const basic_oserializer * pending_bos; basic_oarchive_impl() : num_flushed_objects(0), pending_object(NULL), pending_bos(NULL) {} const cobject_type & find(const basic_oserializer & bos); const basic_oserializer * find(const serialization::extended_type_info &ti) const; public: const cobject_type & register_type(const basic_oserializer & bos); void save_object( basic_oarchive & ar, const void *t, const basic_oserializer & bos ); void save_pointer( basic_oarchive & ar, const void * t, const basic_pointer_oserializer * bpos ); void flush(); }; ////////////////////////////////////////////////////////////////////// // implementation of basic_oarchive implementation functions // given a type_info - find its bos // return NULL if not found inline const basic_oserializer * basic_oarchive_impl::find(const serialization::extended_type_info & ti) const { class bosarg : public basic_oserializer { bool class_info() const { assert(false); return false; } // returns true if objects should be tracked bool tracking() const { assert(false); return false; } // returns class version unsigned int version() const { assert(false); return 0; } // returns true if this class is polymorphic bool is_polymorphic() const{ assert(false); return false; } void save_object_data( basic_oarchive & ar, const void * x ) const { assert(false); } public: bosarg(const serialization::extended_type_info & type_) : boost::archive::detail::basic_oserializer(type_) {} }; bosarg bos(ti); cobject_info_set_type::const_iterator cit = cobject_info_set.find(cobject_type(bos)); // it should already have been "registered" - see below if(cit == cobject_info_set.end()){ // if an entry is not found in the table it is because a pointer // of a derived class has been serialized through its base class // but the derived class hasn't been "registered" return NULL; } // return pointer to the real class return cit->bos_ptr; } inline const basic_oarchive_impl::cobject_type & basic_oarchive_impl::find(const basic_oserializer & bos) { std::pair<cobject_info_set_type::iterator, bool> cresult = cobject_info_set.insert(cobject_type(cobject_info_set.size(), bos)); return *(cresult.first); } inline const basic_oarchive_impl::cobject_type & basic_oarchive_impl::register_type( const basic_oserializer & bos ){ cobject_type co(cobject_info_set.size(), bos); std::pair<cobject_info_set_type::const_iterator, bool> result = cobject_info_set.insert(co); return *(result.first); } inline void basic_oarchive_impl::save_object( basic_oarchive & ar, const void *t, const basic_oserializer & bos ){ // if its been serialized through a pointer and the preamble's been done if(t == pending_object && pending_bos == & bos){ // just save the object data ar.end_preamble(); (bos.save_object_data)(ar, t); return; } // get class information for this object const cobject_type & co = register_type(bos); if(bos.class_info()){ if( ! co.initialized){ ar.vsave(class_id_optional_type(co.class_id)); ar.vsave(tracking_type(bos.tracking())); ar.vsave(version_type(bos.version())); (const_cast<cobject_type &>(co)).initialized = true; } } // we're not tracking this type of object if(! bos.tracking()){ // just windup the preamble - no object id to write ar.end_preamble(); // and save the data (bos.save_object_data)(ar, t); return; } // look for an existing object id object_id_type oid(object_set.size() + num_flushed_objects); // lookup to see if this object has already been written to the archive basic_oarchive_impl::aobject ao(t, co.class_id, oid); std::pair<basic_oarchive_impl::object_set_type::const_iterator, bool> aresult = object_set.insert(ao); oid = aresult.first->object_id; // if its a new object if(aresult.second){ // write out the object id ar.vsave(oid); ar.end_preamble(); // and data (bos.save_object_data)(ar, t); return; } // check that it wasn't originally stored through a pointer if(stored_pointers.end() != stored_pointers.find(oid)){ // this has to be a user error. loading such an archive // would create duplicate objects boost::throw_exception( archive_exception(archive_exception::pointer_conflict) ); } // just save the object id ar.vsave(object_reference_type(oid)); ar.end_preamble(); return; } // save a pointer to an object instance inline void basic_oarchive_impl::save_pointer( basic_oarchive & ar, const void * t, const basic_pointer_oserializer * bpos_ptr ){ const basic_oserializer & bos = bpos_ptr->get_basic_serializer(); std::size_t original_count = cobject_info_set.size(); const cobject_type & co = register_type(bos); if(! co.initialized){ ar.vsave(co.class_id); // if its a previously unregistered class if((cobject_info_set.size() > original_count)){ if(bos.is_polymorphic()){ const serialization::extended_type_info *eti = & bos.type; const char * key = NULL; if(NULL != eti) key = eti->key; if(NULL != key){ // the following is required by IBM C++ compiler which // makes a copy when passing a non-const to a const. This // is permitted by the standard but rarely seen in practice const class_name_type cn(key); // write out the external class identifier ar.vsave(cn); } else // without an external class name // we won't be able to de-serialize it so bail now boost::throw_exception( archive_exception(archive_exception::unregistered_class) ); } } if(bos.class_info()){ ar.vsave(tracking_type(bos.tracking())); ar.vsave(version_type(bos.version())); } (const_cast<cobject_type &>(co)).initialized = true; } else{ ar.vsave(class_id_reference_type(co.class_id)); } // if we're not tracking if(! bos.tracking()){ // just save the data itself ar.end_preamble(); state_saver<const void *> x(pending_object); state_saver<const basic_oserializer *> y(pending_bos); pending_object = t; pending_bos = & bpos_ptr->get_basic_serializer(); bpos_ptr->save_object_ptr(ar, t); return; } object_id_type oid(object_set.size() + num_flushed_objects); // lookup to see if this object has already been written to the archive basic_oarchive_impl::aobject ao(t, co.class_id, oid); std::pair<basic_oarchive_impl::object_set_type::const_iterator, bool> aresult = object_set.insert(ao); oid = aresult.first->object_id; // if the saved object already exists if(! aresult.second){ // append the object id to he preamble ar.vsave(object_reference_type(oid)); // and windup. ar.end_preamble(); return; } // append id of this object to preamble ar.vsave(oid); ar.end_preamble(); // and save the object itself state_saver<const void *> x(pending_object); state_saver<const basic_oserializer *> y(pending_bos); pending_object = t; pending_bos = & bpos_ptr->get_basic_serializer(); bpos_ptr->save_object_ptr(ar, t); // add to the set of object initially stored through pointers stored_pointers.insert(oid); } // replaces addresses of objects in the object_set with NULL so that // future objects will be duplicated, but object_id's will be // preserved. inline void basic_oarchive_impl::flush() { num_flushed_objects += object_set.size(); object_set.clear(); } ////////////////////////////////////////////////////////////////////// // implementation of basic_oarchive functions BOOST_DECL_ARCHIVE basic_oarchive::basic_oarchive() : pimpl(new basic_oarchive_impl) {} BOOST_DECL_ARCHIVE basic_oarchive::~basic_oarchive() { delete pimpl; } void BOOST_DECL_ARCHIVE basic_oarchive::save_object( const void *x, const basic_oserializer & bos ){ pimpl->save_object(*this, x, bos); } void BOOST_DECL_ARCHIVE basic_oarchive::save_pointer( const void * t, const basic_pointer_oserializer * bpos_ptr ){ pimpl->save_pointer(*this, t, bpos_ptr); } void BOOST_DECL_ARCHIVE basic_oarchive::register_basic_serializer(const basic_oserializer & bos){ pimpl->register_type(bos); } unsigned int BOOST_DECL_ARCHIVE basic_oarchive::library_version() const{ return ARCHIVE_VERSION(); } void BOOST_DECL_ARCHIVE basic_oarchive::end_preamble(){ } void BOOST_DECL_ARCHIVE basic_oarchive::flush(){ pimpl->flush(); } } // namespace detail } // namespace archive } // namespace boost #ifdef BOOST_MSVC #pragma warning(pop) #endif #ifndef BOOST_ARCHIVE_BASIC_OARCHIVE_HPP #define BOOST_ARCHIVE_BASIC_OARCHIVE_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // basic_oarchive.hpp: // (C) Copyright 2002 Robert Ramey - http://www.rrsd.com . // Use, modification and distribution is subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) // See http://www.boost.org for updates, documentation, and revision history. #include <boost/config.hpp> #include <boost/detail/workaround.hpp> // can't use this - much as I'd like to as borland doesn't support it // #include <boost/scoped_ptr.hpp> #include <boost/archive/basic_archive.hpp> #include <boost/serialization/tracking.hpp> #include <boost/archive/detail/abi_prefix.hpp> // must be the last header namespace boost { namespace archive { namespace detail { class BOOST_DECL_ARCHIVE basic_oarchive_impl; class BOOST_DECL_ARCHIVE basic_oserializer; class BOOST_DECL_ARCHIVE basic_pointer_oserializer; ////////////////////////////////////////////////////////////////////// // class basic_oarchive - write serialized objects to an output stream class BOOST_DECL_ARCHIVE basic_oarchive { friend class basic_oarchive_impl; // hide implementation of this class to minimize header conclusion // in client code. note: borland can't use scoped_ptr //boost::scoped_ptr<basic_oarchive_impl> pimpl; basic_oarchive_impl * pimpl; // overload these to bracket object attributes. Used to implement // xml archives virtual void vsave(const version_type t) = 0; virtual void vsave(const object_id_type t) = 0; virtual void vsave(const object_reference_type t) = 0; virtual void vsave(const class_id_type t) = 0; virtual void vsave(const class_id_optional_type t) = 0; virtual void vsave(const class_id_reference_type t) = 0; virtual void vsave(const class_name_type & t) = 0; virtual void vsave(const tracking_type t) = 0; protected: basic_oarchive(); virtual ~basic_oarchive(); public: unsigned int library_version() const; void save_object( const void *x, const basic_oserializer & bos ); void save_pointer( const void * t, const basic_pointer_oserializer * bpos_ptr ); void register_basic_serializer(const basic_oserializer & bos); void save_null_pointer(){ vsave(NULL_POINTER_TAG); } void end_preamble(); // default implementation does nothing void flush(); }; } // namespace detail } // namespace archive } // namespace boost // required by smart_cast for compilers not implementing // partial template specialization BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION( boost::archive::detail::basic_oarchive ) #include <boost/archive/detail/abi_suffix.hpp> // pops abi_suffix.hpp pragmas #endif //BOOST_ARCHIVE_BASIC_OARCHIVE_HPP

2 1

[Boost-bugs] [ boost-Bugs-1157766 ] build process still hangs on xml_grammar.cpp
by SourceForge.net 06 Mar '05

06 Mar '05

Bugs item #1157766, was opened at 2005-03-06 15:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1157766&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastian (pinguin751) Assigned to: Nobody/Anonymous (nobody) Summary: build process still hangs on xml_grammar.cpp Initial Comment: as suggested in this thread: http://lists.boost.org/MailArchives/boost/msg76792.php the build process still hangs on MacOSX when building xml_grammar.cpp (boost v1.32). the system has very high load, gcc fetches more and more memory til the system is constantly swapping ... with this fix: <darwin><release><inlining>off added to build of "serialisation" and "wserialisation" the problem could be solved (as already suggested in the mail listed above) also interesting could be this: http://lists.boost.org/MailArchives/boost/msg77573.php pls include a/the fix it into the src base thx regards, seb ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1157766&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[somewhat OT] BGL-based graph library
by Maxim Khesin 06 Mar '05

06 Mar '05

Hello Folks, I recently started working on a graph-algorithms library in Python. What makes this one different from the other couple of libs that are available is a heavy influence from the C++ Boost Graph Library. This is a sort of an exploration in Concept in Python without loosing the Pythonness :). There is no official code release so far, but I have been blogging ideas and code snippets here: http://pythonzweb.blogspot.com/. I already invited Jeremy Siek of BGL fame to comment, and any other comments from boost/BGL community would be most welcome (you can leave them right on the blog). thanks, max.

4 5

Unhackable Wiki
by David Abrahams 06 Mar '05

06 Mar '05

I don't see any reason our Wiki should be so vulnerable, and before we make it official I would insist that we fix that. The Boost list never gets spammed, and moderators don't even seem to have to reject any spammers. All we need to do is use the same approval and posting process for the Wiki. Is something wrong with that? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 6