- Boost - lists.boost.org

Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
by Vinnie Falco 09 Jul '17

09 Jul '17

On Mon, Jul 3, 2017 at 9:54 AM, Emil Dotchevski via Boost <boost(a)lists.boost.org> wrote: > ... > The question is must Beast be coupled to Asio, not can it be used without > something like Asio. And I don't mean just in the case of someone using > serializer/basic_parser and nothing else. > > In my opinion, arguing that coupling is necessary should begin with > defining an interface which Beast can use, which can be trivially > implemented in terms of Asio. In designing this interface the only concern > should be avoiding the coupling; specifically, performance considerations > should be completely ignored. Only then we can have a reasonable discussion > is it worth it. Regardless, in my experience this kind of exercise always > improves the design of a library. The question is, can Beast be written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams, instead of being tied to Boost.Asio? First lets imagine what such generic concepts might look like, independent of Beast. We will start with the synchronous case which is the easiest. In the code which follows: * `Stream` is a type representing a buffer oriented I/O stream * `Buffers` is type representing an ordered sequence of zero or more non-owning references to contiguous octet buffers * `Error` is type representing an error code The following synchronous stream operations are defined: /** Read data from a stream synchronously `stream` The stream to read from `buffers` The buffers to read into `error` Set to the error if any occurred. returns: The number of bytes transferred, or 0 on error. */ std::size read( Stream& stream, Buffers const& buffers, Error& error); /** Write data to a stream synchronously `stream The stream to write to `buffers The buffers to write from `error` Set to the error if any occurred. returns: The number of bytes transferred, or 0 on error. */ std::size_t write( Stream& stream, Buffers const& buffers, Error& error); This looks pretty generic and at this point users familiar with Boost.Asio might raise their hands to tell me that the interfaces look identical. This is just a coincidence because, lets face it - synchronous interfaces don't come in that many varieties. I don't think synchronous interfaces are particularly interesting and Beast could certainly be made to use something like this but even with simple interfaces some issues come up: 1. What is the concrete type of Error? Or is Error a template parameter that meets certain requirements? 2. HTTP stream read algorithms need to know when the stream, is closed, what error code represents End-of-File? 3. What are the requirements of Buffers? Beast could be written against generic concepts, but in order to do so the questions above need to be answered (points 1 through 3). Otherwise there is no specification and thus, no way to write an algorithm. We will come back to these questions, but now on to the next topic. We want Beast to also provide HTTP operations on asynchronous streams, so we need to have a generic concept against which to work. There are many models of asynchronous computation. For example there are futures, coroutines, callbacks, and queues (I can't really think of any others at the moment). Lets imagine what callback-based generic asynchronous stream read and write operations might look like: In the code which follows: * `Stream` is a type representing a buffer oriented I/O stream * `Buffers` is type representing an ordered sequence of zero or more non-owning references to contiguous octet buffers * `Error` is type representing an error code * `Callback` is a type which is Callable with the signature `void(Error, std::size_t)` The following asynchronous stream operations are defined: /** Begin an operation to read data from a stream asynchronously `stream` The stream to read from `buffers` The buffers to read into `callback` A callback to invoke when the operation completes. The callback will receive the error if any, and the number of bytes transferred. returns: The number of bytes transferred, or 0 on error. */ void async_read( Stream& stream, Buffers const& buffers, Callback const& callback); /** Begin an operation to write data to a stream synchronously `stream` The stream to write to `buffers` The buffers to write from `callback` A callback to invoke when the operation completes. The callback will receive the error if any, and the number of bytes transferred. returns: The number of bytes transferred, or 0 on error. */ void async_write( Stream& stream, Buffers const& buffers, Callback const& callback); Now anyone who knows Asio is going to stop me and say, hey! This looks a lot like Asio! But that's a side issue because this generic interface I have provided has some defects. Or rather, you can say that it is under-specified. We have the same questions about the requirements for the types Error and Buffers, and the value representing End-of-File. But now there are even bigger questions with significant ramifications: 1. Upon which thread is the callback invoked? 2. Who invokes the callback and how is it invoked? 3. How is access to the `stream` synchronized? 4. What about futures and coroutines? The simple generic free function signatures alone which I provided above are not sufficient to describe a complete model for asynchronous operations on streams. We also need provisions to answer the questions above. Does the implementation provide the threads, or are they provided by the user? Does synchronization use mutexes? Lock-free programming? Queues? Back to this in a moment... Some folks who either dislike callbacks or just happen to love futures may raise an objection that the callback-based generic model I have described does not capture their use case. Actually, Christopher Kohlhoff (author of Boost.Asio) demonstrates how the callback-based model is a proper superset of all other asynchronous computation models. And he shows that callback-based models provide the greatest opportunity for performance and efficiency by doing away with unnecessary synchronization points. This is explained in his paper N3896 "Library Foundations for Asynchronous Operations" and shows how initiating functions like `async_read` and `async_write` above may be trivially modified to support not just callbacks but also futures, coroutines, and user-defined types. Beast fully supports this system and even comes with tutorials and helper classes which let you implement the model yourself in your own initiating functions. "Library Foundations for Asynchronous Operations" (N3896) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3896.pdf> "Writing Composed Operations" (Beast) <http://vinniefalco.github.io/stage/beast/review/beast/using_networking/writ…> Thankfully this solves one piece of our puzzle. N3896 allows us to say with certainty that our hypothetical generic network model should use callbacks as the foundational notification mechanism for the completion of asynchronous operations. Perhaps we can look towards the author of N3896 for more solutions? Drumroll... Working Draft, C++ extensions for Networking (N4588) a.k.a. "Networking-TS" <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4588.pdf> What is this you ask? Well... this is a working draft which describes a proposed set of C++ extensions for Networking. It has TCP/IP sockets and UDP streams, serial ports I think (?) but lets not worry about that. Most importantly, the Networking-TS defines a generic model for synchronous and asynchronous stream-oriented I/O operations! This means that: Synchronous and asynchronous algorithms written against Networking-TS concepts will work with any stream types that meet the requirements ** Yes, Networking-TS comes with generic stream concepts. Lets restate the original question: "Can Beast be written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams?" The answer is: Yes. Beast is already written against generic concepts which define synchronous and asynchronous operations over buffer oriented streams. These are provided by Boost.Asio. Specifically, these concepts: SyncReadStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.stream.reqmts.sync…> SyncWriteStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.stream.reqmts.sync…> AsyncReadStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.async.read> AsyncWriteStream <https://timsong-cpp.github.io/cppwp/networking-ts/buffer.async.write> Its not the responsibility or goal of Beast to invent a new generic model of synchronous or asynchronous networking. That's already been taken care of. Beast follows it. It is the job of authors to make sure their network implementations meet the requirements of the various Networking-TS stream concepts. Once they do that, then any algorithms written against the concepts can now work with these implementations. Again folks might raise their hand and say "but Beast depends on Boost.Asio!" and they would be right. The reality is that Networking-TS has not entered the standard and is not uniformly available across compiler vendors. Boost.Asio is the closest thing to the standardized version of Networking-TS, so Beast is written against that. Its not perfect, but it is the best we can do and the runner-up is not even in the race (are there any other generic stream designs?). I believe that the burden of proof rests with those who claim that Beast should be written against a different generic stream design. Please show me one such design that is mature, well-specified, and in-use, other than Boost.Asio. tl;dr; Boost.Asio's models of synchronous and asynchronous buffer-oriented streams are already generic, and Beast is written against Boost.Asio. Thanks

2 1

Re: [boost] Boost 1.65.0 Beta 1 Release Candidate 1
by berne＠notadragon.com 09 Jul '17

09 Jul '17

Hi, I've been playing aournd with boost coroutines2 and maybe I'm just confused about where this project is, but with 1.65 coroutines2 doesn't seem to be buildable out of the box any longer: I've tried looking through mailing list archives for anything about the status of coroutine2 to no avail, and coroutine still spits out warnings to use coroutine2 when used. I'm not sure where in the build system things hook in to fix this. Here's the output on my system: berne@Bugg:~/tmp$ tar xzf boost_1_65_0_beta1_rc1.tar.gz berne@Bugg:~/tmp$ cd boost_1_65_0/ berne@Bugg:~/tmp/boost_1_65_0$ ./bootstrap.sh --with-toolset=clang Building Boost.Build engine with toolset clang... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in project-config.jam... Bootstrapping is done. To build, run: ./b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/doc/html/index.html berne@Bugg:~/tmp/boost_1_65_0$ ./b2 --with-coroutine2 error: wrong library name 'coroutine2' in the --with-<library> option. Thanks. - Josh

2 2

[beast] Review
by Gyorgy Szekely 09 Jul '17

09 Jul '17

Hi, Some background: this is my first Boost library review. I followed the discussion on Beast and I'm probably not as experienced as others on this topic. I started learning Beast along with Asio and it was a really good experience. After understanding ASIO concepts, I could get an async multi-threaded http server running in a few hours. I leave it up to the review manager whether to take this a formal review or just informal feedback (impressions of newbie :)) *** What is your evaluation of the design? The library in my opinion is very well designed. I doesn't try to offer too much. I understand the author's position: HTTP is vast and Beast is a low-level library. Still, while using it I felt with a few additional bits it would be more complete. What I was missing is parsers/serializers for uri and cookies. I think Beast should provide these (even in a separate namespace), as they are not higher level functionality than parsing/serializing http headers. (I implemented them in my application, and I'm sure my code is neither correct regarding corner cases, nor standards compliant. I'm also sure that I'm not alone with this, so there's a place for this in either Beast, or as the author suggests a higher level lib.) Though the library is heavily templated, as a user I'm not forced to write templated code, implementing the most common use-cases is simple and straightforward. That's a big plus. I really like the symmetric client/server design. My application is http/websocket server, being able to use the the same classes and functions in unit tests made reasoning about the code and tests much easier. Finally there's was a lot of debate whether being ASIO and stream concept based is a good idea or not. For me (as a newcomer) seamless integration with ASIO helped getting started really fast, though I didn't do awfully complex stuff. *** What is your evaluation of the implementation? I did not review all the implementation. While using the library, I looked into some of the files, and my impression was that the code is high quality. The test coverage is also high, and issue fixes are accompanied with rigorous tests. The library is mostly composed of templates, which makes a bit harder to understand its internals, but I didn't mind it at all given the benefits (composablity, customization points). *** What is your evaluation of the documentation? The documentation is well structured and plenty. Sections from the Intro up to the Reference are a good read by themselves. Design decisions and library scope are clearly stated. There're lots of examples in form of code snipets highlighting a particular use-case, as well as fully functional programs demonstrating these in action. I liked that the documentation is similar to ASIO's and I could use them together. *** What is your evaluation of the potential usefulness of the library? It's super useful. Even with its (current) dependency on ASIO and some other Boost libs Beast is small while providing both client and server side foundations for Websocket and HTTP. NodeJS and Java makes it so simple to create REST services, this should be hard in C++ either with standards based (NetTS) solutions. Beast is a step in the right direction. *** Did you try to use the library? With which compiler(s)? Did you have any problems? I'm actively using the library in the Http/Websocket <-> ZeroMQ gateway since Oct 2016 on Ubuntu 16.04 with GCC5, C++14. We've run extensive performance and stability tests on the HTTP interface and we're quite satisfied with the results. I migrated our codebase to newer Beast versions multiple times, and during this I reported a few minor issues or requested new features. The library author was really responsive and fixed/implemented them quickly. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours this time, but I've read the documentation and the public API reference multiple times in the last months. I didn't go through the implementation, but peeked into it here and there to understand some of the details. *** Are you knowledgeable about the problem domain? Not really. I've implemented some NodeJS and Java Spring REST services, but that's all. My conclusion: Beast should be ACCEPTED. Regards, Gyorgy Szekely

1 0

[sort] pdqsort mini-review
by Steven Ross 08 Jul '17

08 Jul '17

The (mini) review for pdqsort will start tomorrow 6/21, and run through 6/30. I will manage the review; Orson Peters is the author. The proposed boost source is here: https://gist.github.com/orlp/24f27aada1ed724d1809b372c33eb92e Documentation is here: https://github.com/orlp/pdqsort#pdqsort And a draft paper is here: https://drive.google.com/open?id=0B1-vl-dPgKm_T0Fxeno1a0lGT0E If you're interested, please answer these questions: 1. Are there any specific concerns you have about pdqsort vs. std::sort? 2. Does it compile for you when you try to use it as a replacement for std::sort? 3. How does the performance compare on your system vs. std::sort? 4. Do you think we should include pdqsort in Boost.Sort? 5. Do you have any concerns about switching the default/fallback sort in Boost libraries (including Boost.Sort) from std::sort to pdqsort?

7 10

[review] Mp11 review starts in one week
by Bjorn Reese 08 Jul '17

08 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

[beast] Missing documentation link
by Bjorn Reese 08 Jul '17

08 Jul '17

The link to example/common/file_body.hpp in the Examples section has gone missing. Please fix this ASAP. All links in the Examples section point the the master branch instead of the review branch.

2 2

[bootstrap] [b2] [install] Intel 17.0 & b2 cmd file for intel64 & vs2017
by Robert 07 Jul '17

07 Jul '17

Hello Everyone, I have had zero responses on the boost-build list since posting June 23, 2017. Hopefully there will be some here. This is most definitely not urgent. There is a chance that a solution in this thread may be important enough to add to a 1.65 jam file. There are many details in order to fully describe the situation. Executive Summary: In order to correctly build Boost 1.64 with the Intel 17.0, Update 4, C++ Windows compiler, in conjunction with Visual Studio (VS) 2017, Update 2, a symbolic link is necessary. The link shortens the VS installation root path for b2.exe to execute correctly. There is a question regarding the correct implementation to modify one or more jam files. The b2.exe automatic detection of the new and different Visual Studio 2017 paths is not working correctly. Details: I have succeeded constructing the b2 complete install for Intel 17.0, Update 4 on Windows 8.1 Pro, 64-bit, in conjunction with Visual Studio 2017, Update 2 (e.g. 15.2 (26430.12), in the About Microsoft Visual Studio dialog). The zlib source and Python 2.7 libraries are also incorporated into the x64 Boost by Intel build. In order to achieve a successful outcome, I create a symbolic link with the mklink command to considerably shorten the value for the VS2017INSTALLDIR environment variable. The value VS2017INSTALLDIR is first set to is: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise The content above triggers two, "input is too long," messages when executing the .\b2 install --prefix=C:\Boost command. The execution never creates the respective b2 cmd file (file name listed below). The Intel supplied batch file is looking for the VS2017INSTALLDIR environment variable, when the vs2017 option is passed to compilervars.bat: compilervars intel64 vs2017 The location of the compilervars.bat is in something similar to: C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2017.4.210\windows\bin Please review https://software.intel.com/en-us/articles/building-boost-with-intel-c-compi… for the recent details from Intel, to build Boost with the Intel compiler on a Windows operating system. The symbolic link is C:\v7 pointing to: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise When the VS2017INSTALLDIR environment variable is C:\v7, then the execution of b2 install at <boost root>\tools\build creates the 32-bit and 64-bit b2_intel-win_17.0_iclvars... command files in C:\Users\<username>\AppData\Local\Temp. I would like to understand whether the b2 constructed output for the file named: b2_intel-win_17.0_iclvars_intel64 vs2017.cmd should have its internal DevEnvDir variable value as this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ or this: DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ If the answer is the latter, then what is the correct modification(s) to the intel-win.jam, user-config.jam, and/or msvc.jam to enable the automatic detection to find the correct location for VS2017's devenv.exe? In order to use the 14.1 Visual Studio version string value, the 1.64 intel-win.jam file has been modified accordingly near the last line: .iclvars-17.0-supported-vcs = "14.1 14.0 12.0 11.0 10.0" ; .iclvars-version-alias-vc14.1 = vs2017 ; I have manually replaced the following strings of the b2_intel-win_17.0_iclvars_intel64 vs2017.cmd file to use the new Visual Studio 2017 paths. For example, the following older VS 2015 paths are equivalent to the following new VS 2017 paths (using the C:\v7 symbolic link above). Note that some paths are very long in VS2015. The VS2017 equivalent can be longer. The replacement string is preceded by the "==>" character combination. C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VC\ ==> C:\v7\Common7\IDE\VC\ C:\Program Files (x86)\MSBuild\14.0\bin\amd64 ==> C:\v7\MSBuild\15.0\Bin\amd64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 ==> C:\v7\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\VCPackages ==> C:\v7\Common7\IDE\VC\vcpackages C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE ==> C:\v7\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools ==> C:\v7\Common7\Tools C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\x64 ==> C:\v7\Team Tools\Performance Tools\x64 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools ==> C:\v7\Team Tools\Performance Tools\ C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow ==> C:\v7\Common7\IDE\CommonExtensions\Microsoft\TestWindow C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\ ==> C:\v7\Common7\IDE\PrivateAssemblies\ The affected cmd variables are: DevEnvDir INCLUDE LIB LIBPATH Path VCIDEInstallDir __VSCMD_PREINIT_INCLUDE __VSCMD_PREINIT_LIBPATH __VSCMD_PREINIT_PATH Thank you for your time and attention. It is greatly appreciated. Sincerely, Robert

1 0

[beast] Review
by Marcel Ebmer 07 Jul '17

07 Jul '17

Here's my Review: DESIGN ====== The design of concepts, data structures and algorithms is mostly done well, with only minor concerns: - The smell of two-phase initialization. Required message properties like method and target have to be set from outside. This makes me as a library user afraid of forgetting something vital. The same holds for prepare_payload(). If I forget to call prepare_payload() or forget to set one of the required message properties or fields, my program may - in the worst case - appear to work correctly. - Inconsequent application of automagic. WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent. Also, the very first WebSocket example in the docs makes it clear that while a close from the peer is handled automagically under the above condition, a close from my side is quite tedious to write. There should be a utility in the library to do the draining for me. - The naming of BodyReader and BodyWriter initially got me confused. In my mind, I 'read' a body FROM a stream/buffer, I 'write' it INTO a stream or buffer. The library uses the terms in the reverse sense. This is not incorrect of course, but my initial confusion may be a sign of suboptimal naming. IMPLEMENTATION ============== Didn't look in-depth. DOCUMENTATION ============= The documentation is very well structured. It is complete in many, but not all places. - A minimalistic HTTP server example would have helped me get started. Just something very, very basic. Reply to each request with "your request was". - In some places, non-self-explanatory function names suddenly pop up without being first introduced. For example, in the section "Using WebSocket"."Send and Receive Messages", text() and got_text() could use some explanation. In the same section, the reference to set_option() seems out-of-place and makes me wonder what I missed. - Since the documentation features comparison with other libraries, it may be worth comparing pion (https://github.com/splunk/pion) as well. - Many reference pages could use some prosaic explanation. For example, my uncertainty concerning message.prepare_payload() might have been alleviated, were it more clear what the function is intended for and what the effect of omitting it would be. SCOPE ===== Since the FAQ is quite defensive in regard to the library's scope, I feel this is worth some discussion. I found the scope to be just right for now, but with future potential. As it is, the library takes away all the tedious protocol stuff, while leaving all important design decisions to the user. It feels like an extension to ASIO. However, there's no apparent reason why (e.g.) request targets shouldn't be URL-decoded, and why form data should not be parsed into a map of some kind. The way I see it, none of this added funtionality would interfere with the library's design. It would, however, make the library user's life a whole lot easier, and probably attract more users as well. USEFULNESS ========== See SCOPE. Very valuable, could be even better. HOW MUCH EFFORT & TRIED TO USE ============================== I invested about a day into the review, read the documentation and ported a small REST-like service from pion to Beast. I may be biased towards Beast due to temporal proximity, but I feel the latter made the code easier to reason about and, at the very least, did not hurt performance. I used gcc 7.1 and clang 4.0. On the review branch, none of the two had any issues. I deliberately did NOT follow the discussion on the mailing list, in order to remain as unbiased as practicable. HOW KNOWLEDGABLE AM I? ====================== I have worked on several HTTP servers and experimented with writing an HTTP server library a few years back. I have no practical experience with WebSockets. IN ONE SENTENCE =============== Beast should be ACCEPTED into Boost. Marcel

2 3

[build] No output until an action completes?
by Tom Westerhout 07 Jul '17

07 Jul '17

Greetings! I've run into a problem that a Boost.Build action produces no output until the command returns. For example, in my Jamfile I have rule do-measure ( test-name : sources * : requirements * ) { ... some preparation work ... } actions do-measure { $(COMMAND) $(ARGS) } notfile ha : @do-measure : ... : ... ; COMMAND is a Python script that runs for a long time and produces some debug information. But b2 does not print this output until COMMAND returns. This is really unfortunate because Travis requires a command to produce output at least once per 10 mins or something. Otherwise it thinks the command has stalled and terminates it. Is there some configuration parameter or a trick to make b2 print the debug info COMMAND produces? or maybe some dummy output so that Travis allows it to run longer than 10 mins? Any help is highly appreciated! Tom

2 2

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0