- Boost - lists.preview.boost.org

[thread] wrong assertion following call to pthread_mutex_timedlock()?
by Wolfgang Fertsak 02 Sep '08

02 Sep '08

In boost 1.35 and 1.36 the implementation of mutex::timed_lock() and recursive_mutex::timed_lock() for posix-platforms with BOOST_PTHREAD_HAS_TIMEDLOCK defined looks like this: bool timed_lock(system_time const & abs_time) { struct timespec const timeout=detail::get_timespec(abs_time); int const res=pthread_mutex_timedlock(&m,&timeout); BOOST_ASSERT(!res || res==EBUSY); return !res; } The assertion following pthread_mutex_timedlock() always fails in case of a timeout since the system call returns ETIMEDOUT when timed out and not EBUSY (according to the open group specification http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timed…) Best regards, Wolfgang

2 1

Re: [boost] Try-out Adler-32 code?
by Bram Neijt 02 Sep '08

02 Sep '08

Hi Daryle, I tried publishing an MD5 algorithm inside one of my programs as a debian package, but there where problems with the licensing. Please take care that the implementation is fully licensed and you mention the right parties everywhere. I'm not sure how you should go about this, but these are just my 2 cents ;) Bram On Mon, 2008-09-01 at 16:03 -0400, Daryle Walker wrote: > I added Adler-32 code to the MD5 trial library at <http:// > svn.boost.org/trac/boost/browser/sandbox/md5>, if anyone would like > to try it out and comment. >

3 2

Re: [boost] [flyweight] post-review version available
by Johannes Brunen 02 Sep '08

02 Sep '08

Hello, Joaqu?n M L?pez Mu?oz wrote: > I forgot to mention that this version has to be built against the > trunk version of Boost (it uses boost::swap, which hasn't made it > to any Boost release yet). Would it possible to provide a version compatible with the current 1.36.0 release. Until version 1.38.0 is quite some time and I would be interested in playing with the library. However, I'm only working with the release package of the boost libraries. Best, Johannes ____________ Virus checked by G DATA AntiVirusKit Version: AVK 19.274 from 02.09.2008 Virus news: www.antiviruslab.com

2 1

Should we provide hot fixes?
by Beman Dawes 02 Sep '08

02 Sep '08

Although it does look like we will be able to hold to a quarterly release schedule, it is really doubtful we have enough resources to issue point releases. To get bug fixes into user's hands more quickly, should we provide hot fixes when appropriate? Hot fixes might work something like this. (I'll use an embarrassing Boost.Filesystem mistake I made as an example.) * Individual developers will decide on a case-by-case basis if they want to provide a hot fix for a given bug. * There would be a prominent link on the web site to a "Hot Fixes" page in the trac. * That "Hot Fixes" page would have a section for each release. * Under release 1.36.0, there would be a changeset number, a description of the problem, and a directory-location: 48192 Restore deprecated basic_directory_entry names inadvertently removed. (boost/filesystem) * The changeset number would link to http://svn.boost.org/trac/boost/changeset/48192 * The "Hot Fixes" page would include instructions on how to apply a changeset. The instructions are the same for all operating systems: -- Click on "Download in other formats: Unified Diff". -- From the command prompt, cd directory-location patch <download-location/changeset_r48192.diff * The "Hot Fixes" page would include instructions on how to install "patch" for popular operating systems, and give an example of actual usage. Comments? --Beman

23 81

Try-out Adler-32 code?
by Daryle Walker 01 Sep '08

01 Sep '08

I added Adler-32 code to the MD5 trial library at <http:// svn.boost.org/trac/boost/browser/sandbox/md5>, if anyone would like to try it out and comment. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[interprocess][process] Synchronizing libraries and efforts (+ bugs)
by Ion Gaztañaga 01 Sep '08

01 Sep '08

Hi to all, I recently needed s library to launch processes and I took a look to the recently announced Process 0.2 (http://lists.boost.org/Archives/boost/2008/07/139322.php) I just needed the library for Windows, and I think the library is interesting although still lacking in some basic aspects (explained later in this post). A process-launching library is a very nice utility for Interprocess and I was thinking of adding this possibility for a future version (Boost 1.37 or 1.38) of the library. If Boost.Process is going forward, it would be glad to collaborate and develop a library that can satisfy all our needs and plays nicely with Interprocess. My main requests for a process-launching library are: 1) Ability to launch a process and a blocking or non-blocking wait operation to obtain its result (Boost.Process already has this). 2) Ability to redirect child process stdin/stdout/stderr to /dev/null, to share the stdin/stdout of the parent or to redirect it to a file. And in the latter case, append or overwrite options (Boost.Process implements some of this options). I slightly modified Boost.Process to implement a rought version of file redirection. 3) Ability to modify the environment variables of the child (Boost.Process already has this). 4) Blocking and non-blocking redirections of stdout and helper functions to simplify its usage (Boost.Process does not have this). For example: bool send_stdio_and_get_stdout (const void* stdin, std::size_t stdin_size, std::vector<char> &stdout); or similar would avoid many programming errors because at any moment stdin can block and we must extract stdout so that the child process can continue processing stdin. 5) I don't know if streams are the right way to communicate with processes, because they don't offer non-blocking support. 6) I think that process-launching interface should be similar to the soon to be standardized C++ futures. So I'm interested in a process-launching library and I offer my collaboration in case Boost.Process development needs help. Regards, Ion PS: Some possible bugs found on Boost.Process 0.2 version (Windows): -> main thread handle returned by CreateProcess in PROCESS_INFORMATION structure the must be closed and I can't find this in the code. -> child::wait function returns sporadic errors when multiple children are launched and waited. I changed the code from: do { ::GetExitCodeProcess(handle_, &code); ::Sleep(500); } while (code == STILL_ACTIVE); ::WaitForSingleObject(handle_, 0); ::CloseHandle(handle_); with ::WaitForSingleObject(handle_, INFINITE); ::GetExitCodeProcess(handle_, &code); ::CloseHandle(handle_); ->environment::set does not correctly overwrite existing variables): void set(const std::string &var, const std::string &value) { insert(value_type(var, value); } should be void set(const std::string &var, const std::string &value) { this->operator[](var) = value; } -> Using named pipes has been problematic because it returns errors when launching multiple processes aggressively: Error 231 - All Pipes are Busy. This does not happen with anonymous pipes and I think it has some relationship with the guid code. By the way, I think a uuid library is too much to create a unique identifier to be shared with the child a simple atomic count would to the job in my opinion. That would reduce Boost.Process dependencies. -> systembuf::close() should call sync() to push the last charaters into the pipe, othewise, characters are lost if the user does not flush the stream. -> I've changed the "stream_info::usefile" case in win32_start to support redirecting to files, changing "CREATE_NEW" parameter of CreateFileA with CREATE_ALWAYS. -> And now, the most important one ;-) Please, avoid tabs! Read boost development guidelines: http://www.boost.org/development/requirements.html#Tabs

3 10

[serialization][frame] Is there any interest in a frame serialization library?
by vicente.botet 01 Sep '08

01 Sep '08

Hi, >From wikipedia "a frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames." Is there any interest in a frame library which will be based on an extension of the archive concept. The saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the begining of the archive. The saving frame concept will allows to save serializable data either at the end or the *begin* of the frame, and the loading frame concept allows to read serializable data from the begining or the *end* of the archive. I'm not sure which syntax will be the more adequated. The serialization library use the <<, >>, and & operators that are associative from left to right. We need the equivalent operators from right to left. <<=, >>=, and &= seams to be the more adequated candidates but I don't know if it is correct in C++ to define this operators with this prototype template <typename T> frame& operator<<=(const T&, frame&); template <typename T> frame& operator>>=(const T&, frame&); template <typename T> frame& operator&=(const T&, frame&); h1 >>= h2 >>= sf << t2 << t1 ~ (h1 >>= (h2 >>= ((sf << t2) << t1))) sould be equivalent to sa & h1 & h2 & t2 & t1 if sf and sa were empty. The main difference is that we can do it hierarchically. The top layer will create a frame, and serialize its own information elements. frame sf; h_n >>= sf << p_n << t_n; Then this top layer will use a primitive of the lower level having as parameter the frame as payload. primitive_n-1(sf); A primitive at the k level will add its own header and trailer information element to the payload of the upper level void primitive_k(frame& sf) { // ... h_k >>= sf << t_k; // ... another_primitive_k_1(sf); // ... } So the frame allows to serialize top-down. With the archive concept the serialization must be done bottom-up, needing to chain each one of the information element in a list and only when we have all off them we can start the serialization. I think that the frame approach should be more efficient because it avoid to store in dynamic memory the information elements to be serialized, instead they are serialized directly. Loading a frame works as loading an archive, except that we can load also at the end of the frame. This avoids to load the complete archive to load the trailer of the lower levels. lf >>= h_1; // ... t_1 << lf; In addition, it would be greate to have saving/loading frames (I'm not sure but I think that an archive can not be saving and loading at the same time). The same frame can be used as loading, analyzing only some lower levels, and as saving in order to construct other lower levels. This will be very useful for gateways and routers. | L4 |<----------------------------->| L4 | | L3 | | ADAPTATION | | L3 | | L2 |<-->| L2 | | X2 | <--> | X2 | | L1 |<-->| L1 | | X1 | <--> | X1 | It would be greate that the same data that can be serialized on archives, could be serializable on a frame using the same save function. But this works only when we save at the end of the frame. Let me see this using a little example: Class C has 3 information elements to serialize (a, b and c). So the save functions could be something like template <typename ARCHIVE> void C::save(ARCHIVE& sa) { sa & a & b & c; } This save function works well from left to right, but can not be used when saving at the begining of a frame, because the expected result when saving at the begining is | a | b | c | sa | but the result will be | c | b | a | sa | So unhappylly we need a different save function template <typename FRAME> void C::save(FRAME& sa, begin_tag&) { a >>= b >>= c >>= sa; // a >>= (b >>= (c >>= sa)); } Please let me know if you are interested in such a library, and what are your requirements. Robert, do you think that this can be seen as an extension of the serialization library? Best regards, Vicente Juan Botet Escriba

1 0

[log] filtering performance
by Igor Nazarenko 01 Sep '08

01 Sep '08

It seems that the library does quite a bit of work before filtering away a record, unless the logging is turned off entirely. There's at least two mutex locks, some memory allocation, etc. Callgrind claims ~2500 instructions when the record is thrown away by the global severity filter. Shortened callgrind output is in-line below; full output and the test program attached. Compiled by gcc 4.2.3 using boost.build variant=release threading=multi. 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 99,557 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 2,530 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 2,530 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 5,212 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 3,904 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 3,904 => bool basic_severity_logger::open_record() (1x) . 10 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 218,306 => record_pump::~record_pump() (1x) 24,144 => bool basic_severity_logger::open_record() (1x) 10 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 28,963 => record_pump::~record_pump() (1x) 5,074 => bool basic_severity_logger::open_record() (1x) 11 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 28,644 => record_pump::~record_pump() (1x) 5,074 => bool basic_severity_logger::open_record() (1x)

2 1

install boost_1_34_1 on fedora
by keren hochman 01 Sep '08

01 Sep '08

Im trying to install boost_1_34_1 on fedora (reference to http://www.boost.org/doc/libs/1_36_0...-boost-library<http://www.boost.org/doc/libs/1_36_0/more/getting_started/unix-variants.htm…> ) But after make install i receive the following error message: bin/sh: ./tools/jam/src//bjam: No such file or directory Not all Boost libraries built properly. Could anyone advise me ?

1 0

[boost 1.35][thread] Compile error with GCC 3.2
by Alexander Dong Back Kim 01 Sep '08

01 Sep '08

Dear members, I wrote an application using boost thread. It compiled well with GCC 3.4 but not with 3.2. I'm using Boost version 1.35. When I compile the application it shows the following error messages... /usr/local/include/boost-1_35/boost/config/requires_threads.hpp:47:5: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pt hreads (Solaris) or -mthreads (Mingw32)" /usr/local/include/boost-1_35/boost/thread/detail/platform.hpp:67:9: #error "Sorry, no boost threads are available for this platform." /usr/local/include/boost-1_35/boost/thread/thread.hpp:19:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/condition_variable.hpp:18:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/condition.hpp:13: syntax error before `;' token /usr/local/include/boost-1_35/boost/thread/mutex.hpp:18:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/once.hpp:18:2: #error "Boost threads unavailable on this platform" /usr/local/include/boost-1_35/boost/thread/once.hpp:23: type specifier omitted for parameter `once_flag' /usr/local/include/boost-1_35/boost/thread/once.hpp:23: syntax error before `&' token /usr/local/include/boost-1_35/boost/thread/once.hpp: In function `void boost::call_once(...)': The codes were compiled well with boost 1.32 but once I upgraded to 1.35, this error starts occurring. Any ideas or suggestions are welcomed and appreciated. best regards, Alex Kim

2 2

[boost 1.35] Linking problem with GCC 3.2
by Alexander Dong Back Kim 01 Sep '08

01 Sep '08

Hi members, I'm using both GCC 3.2 and 3.4 in different linux machines. The application uses a number of BOOST libraries such as program_options, iosterams, thread and system. When I compiled the application with GCC 3.4 (of course linking correct library files like "libboost_program_options-gcc34-mt"), it compiled well and works well. I did "ldd" to see what library files are linked... and it says... libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0048a000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x005e8000) libm.so.6 => /lib/tls/libm.so.6 (0x00372000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00555000) libc.so.6 => /lib/tls/libc.so.6 (0x0023e000) /lib/ld-linux.so.2 (0x00224000) Now, I compiled the same application and link different gcc version of boost library files because it uses GCC 3.2 instead. I compiled it and there was no compile-time error but it cannot be executed because it can't find the target library files. I did "ldd" for the application and now it has all the boost library files... libpthread.so.0 => /lib/tls/libpthread.so.0 (0x0038d000) libboost_system-gcc32-mt-1_35.so.1.35.0 => not found libboost_thread-gcc32-mt-1_35.so.1.35.0 => not found libboost_serialization-gcc32-mt-1_35.so.1.35.0 => not found libboost_program_options-gcc32-mt-1_35.so.1.35.0 => not found libboost_iostreams-gcc32-mt-1_35.so.1.35.0 => not found libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00b8e000) libm.so.6 => /lib/tls/libm.so.6 (0x007a6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00179000) libc.so.6 => /lib/tls/libc.so.6 (0x00182000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00d66000) Both machine has the same boost 1.35. Only differences is they have different versions of GCC (3.2 and 3.4). Is there any idea or hints where this problem comes from??? regards, Alex Kim

3 4

F# Units of Measurement
by Mårten Rånge 01 Sep '08

01 Sep '08

This is not C++ but since it was used as an example in the boost mpl book maybe it could insterest some. http://blogs.msdn.com/andrewkennedy/ -- Mårten

2 1

lifetime of ranges vs. iterators
by Arno Schödl 01 Sep '08

01 Sep '08

> When stacking N difference_ranges, the size difference between "fat" and "lean" > iterators is 2^N. Thus in fully generic code where you don't know anything about > the stacking depth, even generating a single fat iterator carries a potentially > exponential penalty. > This fact makes me think that range is not merely a fancy name for a pair of > iterators but a concept in its own right between containers and iterators. > Generic algorithms must be written on the basis of ranges rather than iterators > or take a significant performance hit. To be fair, this hit could be avoided by storing the sub-iterators of the difference_iterator in their factored form, e.g., m_ittrav/m_ittravEnd would be stored as m_ittrav/m_ittravEnd/m_travcommon. But this would put a big burden on the compiler to optimize the frequent compose/decompose operations. For example: *m_ittrav; would become *compose( m_ittrav, m_travcommon ) // common data not used at all and ++m_ittrav; would become m_ittrav=decompose( ++compose( m_ittrav, m_travcommon ) ).first; -Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

1 0

Boost 1.36.0 release notes missing Circular Buffer changes
by Dean Michael Berris 01 Sep '08

01 Sep '08

Hi, I took a look at the code in trunk and in 1.36.0, and I notice the release notes don't mention the change in behavior of Boost.Circular_Buffer WRT the default constructor. Should we add: Circular Buffer: * default constructor now doesn't allocate memory, and sets the capacity of the buffer to 0 To the 1.36 release notes? -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

Re: [boost] [review wizard/admin] Not-yet-committed, but accepted libraries
by JOAQUIN M. LOPEZ MUÑOZ 31 Aug '08

31 Aug '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Ronald Garcia [garcia(a)cs.indiana.edu] Enviado el: sábado, 30 de agosto de 2008 18:56 Para: Boost mailing list CC: John R. Phillips Asunto: [boost] [review wizard/admin] Not-yet-committed, but accepted libraries > > A few libraries have been reviewed and accepted into boost, but have > not yet appeared in SVN as far as I can tell. Could some light be > shed on the status of the following libraries? Apologies if I have > simply overlooked any of them: > > Flyweight (Joaquín Mª López Muñoz) I'm glad you ask :) The review raised some important issues that only during this summer I've had the time to attack. I've got everything ready for a post-review version during the following week. My target release is Boost 1.38. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[pointer container] Wishlist: Iterating through nullable vectors and compiler firewalls
by Andrew Hain 31 Aug '08

31 Aug '08

Two quick queries. Would it make sense to have the iterator increment and decrement operators and begin() member function of ptr_vector< nullable<> > skip missing records so that applications have no need to check? What is stopping pointer container classes from being used with opaque types as a compilation firewall? -- Andrew Hain Oasys http://www.oasys-software.com

2 2

[log] Yet more questions for Andrey: formatting severity
by Igor Nazarenko 31 Aug '08

31 Aug '08

By default, severity is printed as integer. What's the easiest way to print the corresponding string (e.g. "info" for severity 0, "warn" for severity 1, and so on)? I tried defining operator<< for my severity enum, but attr<severity_level> doesn't work; that is, the output operator doesn't get invoked (I assume because attribute "Severity" is internally of type "int" and not of my enum type). Thanks a lot! Igor

3 4

Re: [boost] [Boost-users] [filesystem][xpressive] Hotfix patches available for 1.36.0
by Mat Marcus 31 Aug '08

31 Aug '08

On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric(a)boostpro.com> wrote: > Michael Marcin wrote: >> >> If the fixes are not critical enough to justify making a point release >> than they should wait until the next release. > > So you're against hotfixes. <shrug> I would say, take the hotfix if you are > experiencing the problem addressed by the hotfix. Otherwise, wait for the > next release. > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases. - Mat

5 8

[review wizard/admin] Not-yet-committed, but accepted libraries
by Ronald Garcia 31 Aug '08

31 Aug '08

A few libraries have been reviewed and accepted into boost, but have not yet appeared in SVN as far as I can tell. Could some light be shed on the status of the following libraries? Apologies if I have simply overlooked any of them: Flyweight (Joaquín Mª López Muñoz) Binary Int (Matt Calabrese) Floating Point Utilities (Johan Råde) Factory (Tobias Schwinger) Forward (Tobias Schwinger) Scope Exit (Alexander Nasonov) Time Series (Eric Niebler) Property Tree (Marcin Kalicinski) -- No documentation in SVN Any information on the whereabouts of these libraries would be greatly appreciated. Cheers, ron

2 1

[vault] or maybe sandbox?
by Robert Jones 30 Aug '08

30 Aug '08

I am unclear of what the vault contains, and of its relation to the sandbox. The sandbox is a versioned repository, whereas the the vault appears not to be. What is the workflow here, if there is one? By what path do libraries arrive at Boost proper (ie. part of some release), and where in the process are the review points? Thanks, Rob.

6 7

Opinion and help with implementing futures
by Bram Neijt 30 Aug '08

30 Aug '08

Dear reader, I've been wanting to implement a future in C++ for some time, and combined some code to come up with the attached. The idea is that the future is a function wrapper around a function call which will call the function in a second thread upon creation. Then at a later moment, the future can yield the return value of the wrapped function (or block until this result is know). I'm happy with the result I got so far. It's a very rough draft, and I would like your help to clean up some details: - I would like to have the Future wrapper work with the boost::function< int (argument, argument)> syntax, but I can't figure out how to get the return type from that syntax to allow for the return value to be defined (the d_result member). - What would be the best way to handle function arguments? Binding all the parameters before passing the resulting bound function object seems like the solution, but is it really the best solution? And last but not least: has this already been done and what is the general opinion within the boost community on having a class like this? Greetings, Bram Neijt Attached are two files, one is the Future class and the second is a test program showing it's general functioning. The output of running the test program should show: Creating future Future thread working Main waiting for 3 seconds Future thread working Future thread working Calling upon future to return Future thread working Future thread working Future thread working Future thread working Future thread working Future thread working Future returned: 9

2 1

Proto<markus>::review()(proto::accept);
by Markus Werle 30 Aug '08

30 Aug '08

Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...

3 3

Re: [boost] [filesystem][xpressive] Hotfix patches available for 1.36.0
by Eric Niebler 29 Aug '08

29 Aug '08

Michael Marcin wrote: > If the > fixes are not critical enough to justify making a point release than > they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[filesystem] BOOST_FILESYSTEM_NO_DEPRECATED
by Johan Råde 29 Aug '08

29 Aug '08

The following code does not compile with Boost 1.36 and MSVS 2008: #define BOOST_FILESYSTEM_NO_DEPRECATED #include <boost/filesystem.hpp> In get the following error message: 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(98) : error C2275: 'boost::filesystem::path' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(49) : see declaration of 'boost::filesystem::path' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(100) : error C2275: 'boost::filesystem::wpath' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(65) : see declaration of 'boost::filesystem::wpath' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(103) : error C2275: 'boost::filesystem::path' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(49) : see declaration of 'boost::filesystem::path' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(105) : error C2275: 'boost::filesystem::wpath' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(65) : see declaration of 'boost::filesystem::wpath' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(108) : error C2275: 'boost::filesystem::path' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(49) : see declaration of 'boost::filesystem::path' 1>C:\Program Files\Boost\boost_1_36_0\boost/filesystem/convenience.hpp(110) : error C2275: 'boost::filesystem::wpath' : illegal use of this type as an expression 1> C:\Program Files\Boost\boost_1_36_0\boost/filesystem/path.hpp(65) : see declaration of 'boost::filesystem::wpath' --Johan Råde

2 1

Enabling fast swap optimization for Boost types VC9 SP1.
by Michael Marcin 29 Aug '08

29 Aug '08

The VC team recently released an update to the VC9 standard library that allows them to take advantage of types with fast swap when performing operations like vector realloc. However it appears this optimization is guarded by a trait that must be specialized. Could we specialize std::_Move_operation_category for this version of VC9 to enable this optimization for boost types that can benefit from it? http://tinyurl.com/6h298c Thanks, Michael Marcin

5 19