- Boost - lists.preview.boost.org

Is there interest in a library for object (especially STL object) marshalling?
by Roger Sanders 16 Oct '13

16 Oct '13

Hi there, I'm not totally sure if this is the right "fit" for boost or not. Perhaps this problem isn't general or abstract enough to warrant inclusion within boost, but I thought I'd send an email around to see what people thought. I've written a library that I've been using extensively, both for my own code, and more recently for a large project in my work, that allows STL objects to easily be exchanged over a function call, even if the caller and the target function represent those STL objects using incompatible binary layouts. This is intended in particular to deal with the common problem of sharing STL objects between multiple compiled assemblies, such as a main executable and satellite DLL's. I'm already using this library extensively to exchange STL objects over pure virtual interfaces for a plugin-based application. The traditional advice people give is "don't use STL objects across DLL boundaries", but this is impractical for applications that are heavily modularized, or plugin-based applications with complex interfaces. Dealing with raw arrays and pointers is often difficult and error-prone, hence why we have STL containers to begin with. Returning data from a function call can also become extremely difficult when STL containers aren't used. With an array for example, if the total number of elements cannot be known by the caller, this can lead to fixed-sized buffers being used with hard-coded maximums, or functions requiring multiple calls, either to determine the size of the data, or to free an allocated buffer that's been returned. Attempting to use STL containers across assembly boundaries without addressing STL compatibility issues however basically requires you to use the exact same compiler version and compiler flags when building each assembly, which is not really possible with a plugin system designed to allow third-party plugins, or even simply with assemblies built at different times on different systems, and it's also inconvenient for development, since you can't easily compile just one assembly with debug compiler settings, while leaving the other assemblies compiled with release compiler settings. Ideally, you want the same signature for a function or method, whether the target code is contained within the same assembly or not. The goal is to make these assembly boundaries "invisible", so you can just write the same code to access functions, regardless of where the code for the target function is located. With the help of this library, along with a simple inline wrapper function which the caller is basically unaware of, that can be achieved, and existing code which makes use of STL objects can be shifted into separate assemblies without refactoring. I haven't found another library like this in the public domain, that attempts to solve this issue comprehensively for any type. Some of the points about my current library implementation are as follows: -Fully template based, with all code defined in header files. -Support for all *primary (see exclusions below) STL container types up to C++11, including strings and keyed containers. -Supports infinite nesting of STL container types, IE: std::vector<std::list<std::map<std::wstring, std::stack<unsigned int>>>> -Heavily optimized, with profiled performance comparable to the best possible hand-written marshalling code. -Extensible, so new STL container types, or boost container types for example, and potentially user-defined types, can be supported and marshalled in a consistent manner, even when nested within each other. *The only three containers I'm aware of that I haven't supported yet are std::pair, std::tuple, and std::bitset, although I can include support for them easily enough. Although difficult, I can also think of how to add support for pointer types such as std::shared_ptr, where object lifetime and destruction can be correctly and automatically managed across assemblies when these types are marshalled. The only compiler requirement here is that each assembly uses a compatible C++ ABI, or at least, as much as is required to allow calling a virtual member function on an object that was constructed within another assembly. What I wanted to get an idea on is whether there is any interest in having something like this included as part of boost? Perhaps there's enough scope here for a general "marshalling" library, that would address some other similar concerns in the future? There would be a fair amount of work to do in order to "boostify" the library and write the corresponding documentation, but I'd be willing to do it if there was interest. Any feedback, thoughts, criticisms? Thanks, Roger Sanders.

3 4

Re: [boost] Fastest Data-structure maybe from STL or Boost ..!!
by Andrew Hundt 15 Oct '13

15 Oct '13

On Mon, Oct 14, 2013 at 11:22 PM, Sylvain Bougerel < sylvain.bougerel.devel(a)gmail.com> wrote: > > > It's seems you need 2-dimensional sorting, one dimension for data, one > for > time. I have a library that is written for this kind of real-time analysis > in multi-dimension, it has k-d tree containers that are self re-balancing, > with insertion in fractional amortized time. You can check it out here: > http://spatial.sourceforge.net/ > > I've been wanting to propose it for review on boost, but never got around > to do it, cause I believe the documentation is sub-par. How does this compare to the Spatial Indexes in Boost.Geometry? http://www.boost.org/doc/libs/1_54_0/libs/geometry/doc/html/geometry/spatia… Cheers! Andrew Hundt

2 1

Testing clang in Windows using VC++ RTL with Boost libraries
by Edward Diener 15 Oct '13

15 Oct '13

I have been trying to test clang in Windows using the VC++ RTL with Boost libraries but I am unable to do so with the clang toolset in Boost Build. The main reason for this is that clang in the configuration I want to test only takes a subset of the gcc command-line options but the Boost Build clang toolset is for clang on Linux ( or a Unix-like environment on Windows like cygwin or MingW/msys ). I am neither knowledgable enough or willing enough to try to create such a Boost Build toolset myself. So I am going to stop. I wish the clang people and Chandler Carruth best of luck getting it to work for Windows using VC++ RTL.

2 2

[trac] [predef] No `prefef` component in trac
by Michel Morin 15 Oct '13

15 Oct '13

There is no `predef` component, which will be shipped in Boost 1.55, in trac. Thanks, Michel

2 5

[predef] missing file On MacOS 10.7.5.
by Vicente J. Botet Escriba 15 Oct '13

15 Oct '13

Hi, I'm getting this error clang-darwin.compile.c++ ../../../bin.v2/libs/thread/build/clang-darwin-3.2x/debug/link-static/threading-multi/pthread/thread.o In file included from ../../../libs/thread/src/pthread/thread.cpp:33: In file included from ../../../boost/lexical_cast.hpp:156: In file included from ../../../boost/math/special_functions/sign.hpp:18: In file included from ../../../boost/math/special_functions/detail/fp_traits.hpp:27: In file included from ../../../boost/detail/endian.hpp:9: In file included from ../../../boost/predef/detail/endian_compat.h:11: ../../../boost/predef/other/endian.h:61:25: fatal error: 'sys/endian.h' file not found # include <sys/endian.h> ^ On MacOS 10.7.5. Please could this be fixed? Is there a test on the regression test using this file? Best, Vicente

5 15

Fastest Data-structure maybe from STL or Boost ..!!
by Rahul Mathur 15 Oct '13

15 Oct '13

All, I wish to record 1000 real time data which need to be in sorted order. I used STL MAP which sorts using KEYS and than sorted the value using STL VECTOR, the complete scenario give me almost 6ms of time analysis. The TARGET is to achieve almost 1.5 - 2.0 ms. Also, once this data structure is completely filled I want to delete the first data and replace it with the new data. Can I have the fastest data structure (STL or BOOST) techniques for the same. ~ Thanks!!

5 4

[release/atomic] request permission to merge 86144
by Tim Blechmann 15 Oct '13

15 Oct '13

i'd like to merge r86144 into release. it is not exactly a bugfix, but it enables double-width cas support for msvc, which is rather important for many lock-free algorithms to be lockfree with this toolchain (including some configurations of stack/queue of boost.lockfree). thnx, tim

3 8

Boost ASIO - Client Request TCP Help..!!
by Rahul Mathur 14 Oct '13

14 Oct '13

All, Below is the client request code which makes a CONNECT request to remote SERVER (having IP & PORT#) but gives error code during send() process - --- #include <iostream> #include <string> #include <boost/asio.hpp> namespace opp = boost::asio::ip; struct PacketFormat { unsigned short length; //Length int sequenceNumber; }; int main(int argc, char* argv[]) { std::string port = "8000"; std::string hostname = "X.X.X.X"; boost::asio::io_service io_service; opp::tcp::resolver resolver(io_service); opp::tcp::resolver::query query(hostname, port); opp::tcp::resolver::iterator iter = resolver.resolve(query); opp::tcp::resolver::iterator end; // End marker. // Looking for a successful endpoint connection opp::tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; while (error && iter != end) { socket.close(); socket.connect(*iter++ , error); } if (error) throw boost::system::system_error(error); std::cout << "Connected ..Thanks!! \n" << std::endl; PacketFormat pf; // where PacketFormat is struct defined pf.length = 236; pf.sequenceNumber = 2; std::cout << "Sending Logon Message.. . ..!! \n" << std::endl; std::size_t n = opp::tcp::socket::send(iter, boost::asio::buffer(&pf)); if (n < 0) std::cerr << "ERROR writing to Server .. . ..\n" << std::endl; std::cout << "Logon Message Sent.. . ..Thanks!!\n" << std::endl; if (n < 0) std::cerr << "ERROR writing to Server .. . ..\n" << std::endl; std::cout << "Logon Message Sent.. . ..Thanks!!\n" << std::endl; return 0; } __ The error message obtained is - -- # g++ testclient.cpp -o testclient -lboost_system -lboost_thread testclient.cpp: In function âint main(int, char**)â: testclient.cpp:42: error: no matching function for call to âbuffer(PacketFormat*)â /usr/local/include/boost/asio/buffer.hpp:704: note: candidates are: boost::asio::mutable_buffers_1 boost::asio::buffer(const boost::asio::mutable_buffer&) /usr/local/include/boost/asio/buffer.hpp:717: note: boost::asio::mutable_buffers_1 boost::asio::buffer(const boost::asio::mutable_buffer&, size_t) /usr/local/include/boost/asio/buffer.hpp:733: note: boost::asio::const_buffers_1 boost::asio::buffer(const boost::asio::const_buffer&) /usr/local/include/boost/asio/buffer.hpp:746: note: boost::asio::const_buffers_1 boost::asio::buffer(const boost::asio::const_buffer&, size_t) /usr/local/include/boost/asio/buffer.hpp:762: note: boost::asio::mutable_buffers_1 boost::asio::buffer(void*, size_t) /usr/local/include/boost/asio/buffer.hpp:772: note: boost::asio::const_buffers_1 boost::asio::buffer(const void*, size_t) __ Please help for L#42 "tcp::socket::send()" proper call. I believe above code fine apart from L#42 error. Thanks!!

4 12

Requesting svn access
by Mathias Gaunard 14 Oct '13

14 Oct '13

Hi, There are a couple of warnings generated by unmaintained libraries that I'd like to fix. (In particular https://svn.boost.org/trac/boost/ticket/9115) Would it be possible to have write access so that I can commit these to trunk and then to release?

3 2

[config] Patch for clang.hpp to support clang in Windows using VC++ RTL
by Edward Diener 14 Oct '13

14 Oct '13

Once Boost 1.55 is out the doors can I apply the attached patch for clang when _MSC_VER is defined ? Unfortunately clang in this situation does not currently support the C++11 types char16_t or char32_t ( there is a bug report for this ), and this means trying to compile Boost libraries like type_traits without this patch yields many errors. I would have used the BOOST_WORKAROUND macro but clang does not support a value which gives a single number for the compiler version so I felt that drumming up multiple BOOST_WORKAROUNDs using major/minor/patch version numbers was too much of a hack to bother about.

2 3

Support for BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
by Joaquin M Lopez Munoz 14 Oct '13

14 Oct '13

I understand there's been some discussion about dropping support for compliers with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined. Has some final decision been made about this? Thank you, Joaquín M López Muñoz Telefónica Digital

6 23

[algorithm][array] Inspection report (tabs)
by Michel Morin 14 Oct '13

14 Oct '13

Hi Marshall, An inspection report says that some files contain tabs: ( http://boost.cowic.de/rc/docs-inspect-trunk.html ) algorithm boost/algorithm/cxx14/equal.hpp: *Tab* boost/algorithm/cxx14/mismatch.hpp: *Tab* libs/algorithm/string/doc/external_concepts.html: Unlinked file libs/algorithm/string/test/find_test.cpp: *Tab* libs/algorithm/string/test/split_test.cpp: *Tab* libs/algorithm/test/iterator_test.hpp: *C*, *Lic*, *Tab* array libs/array/doc/Jamfile.v2: *C*, *Lic* libs/array/test/array_constexpr.cpp: *Tab* libs/array/test/array_getfail1.cpp: *Tab* Regards, Michel

1 0

Permission to proceed?
by Stephen Kelly 14 Oct '13

14 Oct '13

Hello, Now that the beta has been out for a while, I'd like to proceed with my clean-up commits in trunk. I'd like to commit the patch in http://thread.gmane.org/gmane.comp.lib.boost.devel/244392/focus=244397 immediately and then proceed to remove the resulting dead code. Can I go ahead and do that? I assume that does not have any effect on the release branch. Thanks, Steve.

6 13

Re: [boost] Improving Documentation
by Andrew Hundt 14 Oct '13

14 Oct '13

On Fri, Oct 11, 2013 at 2:49 PM, Robert Ramey <ramey(a)rrsd.com> wrote: > Mathias Gaunard wrote: > > On 11/10/13 15:31, TONGARI J wrote: > > > >> I think Doxygen is fine for "regular" libraries, but I always have a > >> question: how could a library like Spirit be doucumented with it? > > > > Same as any other library. > > You document the data types and the functions. > > what about the type constraints - aka concepts? > and templates? You can document template parameters with doxygen. If you are using the boost concept check library you can also use those classes to document your concepts. I believe gil does that if you would like an example. You can also always add custom fields fairly easily if none of the existing ones meet you needs. Cheers! Andrew Hundt

5 5

[config][release] Release notes for old compilers.
by Daniel James 14 Oct '13

14 Oct '13

Hi, I added a little release notes for config, and also a note about removing support for older compilers in the future. If this concerns you, please give it a quick check and let me know if you want any changes. This release note is not a promise that future changes will or won't be made, and it can be changed if appropriate. Sorry that this is a bit late. We can still change the release notes after the beta (and final) release, so don't worry about that. thanks, Daniel

5 12

Review request: Require a SFINAE capable compiler
by Stephen Kelly 14 Oct '13

14 Oct '13

Hello, Several of the ancient compilers define BOOST_NO_SFINAE. The attached patch removes support for those versions of the compilers which are not capable of SFINAE. This bumps the compiler requirement to remove support for Borland 5.x, Metrowerks prior to 9.0, and SunPro prior to 5.7. Compilers based on EDG 238 are also affected, though it is unknown what those are. Ok to commit? Thanks, Steve.

6 12

[compiler workaround] Are we purging history?
by Daryle Walker 14 Oct '13

14 Oct '13

As I understand it, the people modernizing Boost code by getting rid of old compiler workarounds are doing two things: 1. Remove the workaround macro flags and the code that uses them, leaving the code that doesn't use the workarounds behind. 2. Purging those workaround macros from Boost.Config. If we are doing [2], why? Doing [1] is sufficient for modernization. Doing [2] is just purging history that we spent blood/sweat/tears generating. Authors/maintainers generally have free reign to use as many or as few workarounds as they want. They can't do that if we're deleting that knowledge from Boost.Config. Daryle W.

3 2

Re: [boost] Improving Documentation
by Andrew Hundt 14 Oct '13

14 Oct '13

On Thu, Oct 10, 2013 at 4:29 PM, Mathias Gaunard < mathias.gaunard(a)ens-lyon.org> wrote: > > Documentation like this is generated by preprocessing Doxygen XML output > to integrate it into Boostbook and have a good look for C++ references. > It has most of what you can expect from Doxygen + the Boostbook stuff > which gives better cross-referencing than simple Doxygen. > > I personally don't understand how one cannot notice that the blue bits > that become underlined when you hover them and change colors once visited > are hyperlinks (especially since that's also true for any other hyperlink > in Boost docs and most of the World Wide Web). > What do you suggest would be better? I believe part of the problem is that everything is blue. For instance, on the boost.lockfree page: http://www.boost.org/doc/libs/1_54_0/doc/html/lockfree/reference.html#heade… - The following words are blue: - namespace, template, bool, struct, capacity, template, typename, allocator, class, fixed_sized, queue, spec_queue, stack - Out of those, the following are links: - fixed_sized, capacity, allocator, queue, spec_queue, stack I believe there is a word to describe the concept of building things such that people expect to interact with them. I think it is called an affordance, so a link should "afford" clicking. https://en.wikipedia.org/wiki/Affordance When it is your first time ever on the site, even if you try to hover over one of the blue words, you may choose one that can't be clicked on, then assume the same applies for the others. IMHO, changing the color of links or making the underlines always visible could be helpful. One possible improvement would be what Mario Mulansky described. In the Table of Contents of libraries the Reference section could contain a list of links to headers, classes, functions, metafunctions, and definitions. Then if you click to the reference link where it currently just lists headers it could also provide the synopsis of the aforementioned items and links to the detailed docs. Right now all of the documentation is an extremely deep hierarchical structure, which if I recall my conventions correctly has been moved away from in modern user experience design. Most websites try to focus on getting you to the information you need in as few clicks as possible. That is why I mentioned cppreference.com in my previous email, if you check out that site nearly everything is 3 levels deep or less. Since boost is so much larger a total of 4 levels with the top one being the list of libraries would make sense. Some link to the libs unit test and/or example folders in each library would also be helpful. These are a couple small, concrete steps that would probably help with browsing but aren't too out there. It doesn't help some of the possibilities for improved text which could also benefit, but it does help many things at a high level. As a side note, I wonder if the boost main page could be better served as a wiki of some sort? Cheers! Andrew Hundt

3 2

[typeof] trunk build broken
by Agustín K-ballo Bergé 12 Oct '13

12 Oct '13

Boost.TypeOf is broken as of revision #85920 due to an invalid preprocessing directive. Patch attached. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

3 3

Re: [boost] Improving Documentation
by Andrew Hundt 12 Oct '13

12 Oct '13

On Friday, October 11, 2013, Mathias Gaunard wrote: > On 11/10/13 00:07, Andrew Hundt wrote: > > I believe part of the problem is that everything is blue. For instance, on >> the boost.lockfree page: >> >> http://www.boost.org/doc/libs/**1_54_0/doc/html/lockfree/** >> reference.html#header.boost.**lockfree.policies_hpp<http://www.boost.org/doc/libs/1_54_0/doc/html/lockfree/reference.html#heade…> >> >> >> - The following words are blue: >> - namespace, template, bool, struct, capacity, template, typename, >> allocator, class, fixed_sized, queue, spec_queue, stack >> > > It's clearly not the same shade of blue though. The links (capacity, > allocator, fixed, queue, spec_queue, stack) are closer to a greenish blue. > Do they appear difficult to distinguish to you? > > Maybe the color palette could be changed. It isn't just me. I believe two others in this email chain mentioned it took them a while to figure out too, and I have had to explain it to other users who are not on this list. The shades certainly don't "pop" and it could just be more syntax highlighting. There isn't anything distinguishing it a a link when you just look at the page and imagine not already being familiar with this documentation layout. Doxygen and other documentation tools don't really have anything like it. > > Some link to the libs unit test and/or example folders in each library >> would also be helpful. >> > > I agree for examples, but I don't think unit tests should appear in the > documentation. > > They can be obscure test cases that users don't need to worry about. > Yeah, it would be great if everything had micro examples at the bottom of each page but often the only thing that exists is a unit test. While it isn't a great situation it would be better than nothing. Cheers! Andrew Hundt

2 1

[type_traits] Variadic function pointer with __fastcall calling convention
by Edward Diener 12 Oct '13

12 Oct '13

In type_traits/detail/is_function_ptr_tester.hpp there are pointer to function signatures being tested which have the __fastcall calling convention and variadic functions. While MSVC accepts this code clang in Windows, which defines _MSC_VER and _MSC_EXTENSIONS, currently gives an error. The justification for giving an error is that __fastcall is a callee stack cleanup calling convention, so it cannot be used for variadic functions. There is a bug report regarding this in the Bugzilla for llvm at http://llvm.org/bugs/show_bug.cgi?id=12535. Comments have been made to me in e-mail and the clang developer's mailing list that it is a type_traits error to allow this, even for MSVC-emulation code. Of course we can temporarily fix this for clang on Windows, possibly with a BOOST_WORKAROUND solution for clang and see if/how clang eventually addresses the bug report. But I would like some sort of resolution so that clang on Windows can compile type_traits in the current Boost trunk.

3 11

[1.55.0] Beta 1 Available
by Marshall Clow 12 Oct '13

12 Oct '13

Boost release 1.55.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.55.0.beta.1/ This release contains 1 new library: * Predef: This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers, from Rene Rivera. For details of what's in the release, see http://www.boost.org/users/history/version_1_55_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 11

results pages not updating
by Michael Mathews 11 Oct '13

11 Oct '13

Neither the trunk nor release results have updated since Wednesday michael

1 0

[1.55][Math] Permission to apply bug fix?
by John Maddock 11 Oct '13

11 Oct '13

Is 1.55 release branch open for bug fixes again? If so I'd like to apply the patch for: https://svn.boost.org/trac/boost/ticket/9183 in https://svn.boost.org/trac/boost/changeset/86205 Many thanks, John.

2 1

Looking for thoughts on a new smart pointer: shared_ptr_nonnull
by Luke Bradford 11 Oct '13

11 Oct '13

Hi, I'm new to this list, so apologies for any oversights or faux pas. I've been finding a lot of use for a type of smart pointer I call shared_ptr_nonnull, which is a variation on shared_ptr which is never allowed to be empty. Specifically: (1) It doesn't have reset() with no arguments, doesn't have a default constructor, and doesn't have implicit conversion to bool (which would always be true.) (2) It throws an exception whenever there's an attempt to make it empty, i.e. in constructors, reset, assignment, and swap. For convenience, it's implicitly convertible to shared_ptr, and I have all of shared_ptr's templated operators implemented with possible combinations of shared_ptr and shared_ptr_nonnull. Usually it can be used just by changing the type of a shared_ptr. We have a lot of shared_ptrs, especially member variables, which are claimed to be "always valid" and this class enforces that, at compile time (1) and runtime (2). Has there been any discussion of something like this? Does anybody have any thoughts, suggestions, criticisms? Who's in charge of the smart pointer library these days? Thanks, Luke

20 113