February 2011 - Boost - lists.preview.boost.org

Using Boost without confusing Intellisense
by Matthew Chambers 10 Feb '11

10 Feb '11

Hi, I use many Boost libraries, develop with MSVC (currently 2008), and build both my project and its Boost dependencies with Boost.Build. The one thing that's always frustrated me using boost is its tendency to confuse MSVC's Intellisense. I don't know if this holds true for other IDEs with an Intellisense-like capability, but heavy use of boost::shared_ptr and BOOST_FOREACH in particular seem to confuse Intellisense in a large project. MSVC never knows what to show when dereferencing a shared_ptr and it never defines the instance variable in BOOST_FOREACH. I came up with two fairly simple workarounds for this but I'm interested to hear if there's a better solution. If not, I'm wondering if the workarounds could go in boost itself. For shared_ptr, I use a conditional macro like: #ifdef INTELLISENSE #define TYPEDEF_SHARED_PTR(type) typedef type* type##Ptr #else #define TYPEDEF_SHARED_PTR(type) typedef boost::shared_ptr<type> type##Ptr #endif For BOOST_FOREACH, I do basically the same thing: #ifdef INTELLISENSE #define BOOST_FOREACH(a, b) a; #else #include <boost/foreach.hpp> #endif Then I just add INTELLISENSE to the VC project's preprocessor macros (not my build system) and Intellisense gets the job done a lot more often. I didn't look into whether MSVC defines an automatic preprocessor variable when Intellisense is parsing (which would be useful for helping it navigate complex code), but of course that would be even better. The obvious flaw for TYPEDEF_SHARED_PTR in my implementation is that it assumes a particular variable name scheme, but an "official" version could make both type names explicit. The are some other confusing libs like Boost.Preprocessor but I don't think they are as commonly used. The nice thing about these workarounds is they can be applied separately to each library. I'm wondering if other boost devs or users would be interested in having these workarounds in the official boost distro. For the smart_ptrs, it could go at the end of the headers. For BOOST_FOREACH, the whole foreach.hpp could be surrounded by #ifndef INTELLISENSE (so that all the stuff inside it doesn't need to be parsed for Intellisense) and the #else would define BOOST_FOREACH and BOOST_REVERSE_FOREACH as I did above. If not, maybe it's time I switched IDEs. Are there any that provide Intellisense-like capability with smart_ptrs and BOOST_FOREACH? :) Thanks, -Matt

9 11

Problem with boost::random seed
by Anton Skvorts 10 Feb '11

10 Feb '11

Testing boost::random with the following code boost::mt19937 gener(1); boost::normal_distribution<> normal(0,1); boost::variate_generator<boost::mt19937 &,boost::normal_distribution<> > rng(gener, normal); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; gener.seed(2); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; I'm getting unexpected values after gener.seed(2) -2.971829031 1.706951063 -0.430498971 -2.282022417 x -0.5887503675 0.2504171986 The value -2.282022417 is the forth number in the sequence originated by gener(1) and not the first number in the sequence originated by gener.seed(2) as one would expect (this number is actually -0.5887503675). If I reseed next with gener.seed(3)it works fine, but if after that I reseed again with gener.seed(1) I'll get the same problem, and so on and off... How can I reseed the random number generator to overcome this problem? Thanks in advance

3 10

[general] What will string handling in C++ look like in the future [was Always treat ... ]
by Matus Chochlik 10 Feb '11

10 Feb '11

The string-encoding-related discussion boils down for me to the following: What fill the string handling in C++ look like in the (maybe not immediate) future. *Scenario A:* We will pick a widely-accepted char-based encoding that is able to handle all the writing scripts and alphabets that we can think of, has enough reserved space for future additions or is easily extensible and use that with std::strings which will become the one and only text string 'container' class. All the wstrings, wxString, Qstrings, utf8strings, etc. will be abandoned. All the APIs using ANSI or UCS-2 will be slowly phased out with the help of convenience classes like ansi_str_t and ucs2_t that will be made obsolete and finally dropped (after the transition). *Scenario B:* We will add yet another string class named utf8_t to the already crowded set named above. Then: library a: will stick to the ANSI encodings with std::strings It has worked in the past it will work in the future, right ? library b[oost]: will use utf8_t instead and provide the (seamles and straightforward) conversions between utf8_t and std::string and std::wstring. Some (many but not all) others will follow library c: will use std::strings with utf-8 ... library [.]n[et]: will use String class ... library q[t]: will use Qstrings .. library w[xWidgets]: will use wxStrings and wxChar* library wi[napi]: will use TCHAR* ... library z: will use const char* in an encoding agnostic way Now an application using libraries [a..z] will become the developers nightmare. What string should he use for the class members, constructor parameters, who to do when the conversions do not work so seamlesly ? Also half of the cpu time assigned to running that application will be wasted on useless string transcoding. And half of the memory will be occupied with useless transcoding-related code and data. *Scenario C:* This is basically the status quo; a mix of the above. A sad and unsatisfactory state of things. *Consequences of A:* - Interface breaking changes, which will require some fixing in the library client code and some work in the libraries themselves. These should be made as painless as possible with *temporary* utilities or convenience classes that would for example handle the transcoding from utf8 to UCS-2/UTF-16 in WINAPI and be no-ops on most POSIX systems. - Silent introduction of bugs for those who still use std::string for ANSI CP####. This is worse than above and will require some public-relations work on the part of Boost to make it clear that using std::strings with ANSI may be an error since Boost version x.y.z. - We should finally accept the notion that one byte, word, dword != one character and that there are code points and there are characters and both of them can have variable length encoding and devise tool to handle them as such conveniently. - Once we overcome the troubled period of transition everything will be just great. No headaches related to file encoding detection and transcoding. Think about what will happen after we accept IPV6 and drop IPV4. The process will be painful but after it is done, there will be no more NAT, and co. and the whole network infrastructure will be simplified. *Consequences of B:* - No fixing of existing interface which IMO means no or very slow moving on to a single encoding. - Creating another string class, which, let us face it, not everybody will accept even with the Boost influence unless it becomes standard. - We will abandon std::string and be stuck with utf8_t which I *personally* already dislike :) - People will probably start to use other programming languages (although this may by FUD) *Consequences of C:* Here pick all the negatives of the above :) *Note on the encoding to be used* The best candidate for the widely-accepted and extensible encoding vaguely mentioned above is IMO UTF-8. - It has been given a lot of thought - It is an already widely accepted standard - It is char-based so no need to switch to std::basic_string<whatever_char_t> - It is extensible, so once we have done the painful transition we will not have to do it again. Currently utf-8 uses 1-4 (or 1-6) byte sequences to encode code points, but the scheme is transparently extensible to 1-N bytes (unlike UCS-X and i'm not sure about UTF-16/32). So, [dark-sarcasm] even if we dig out the stargate or join the United Federation of Planets and captain Kirk, every time he returns home, brings a truckload of new writing scripts to support, UTF-8 will be able to handle it. just my 0.02 strips of gold pressed latinum :) [/dark-sarcasm] Best regards, Matus

23 117

[process] FileSystem version
by vicente.botet 09 Feb '11

09 Feb '11

Hi, with witch version of Boost.FileSystem Boost.Process is working, V2, V3 or both? Best, Vicente

3 4

Re: [boost] [gsoc] Boost.Process done
by Claude Quézel 09 Feb '11

09 Feb '11

I noticed that the boost::process::child does not have a default constructor. If I have a coding requirements like the following example, I would be stuck: // Note the required default constructor boost::process::child child; // Create a scope for the mutex guard { boost::lock_guard<boost::mutex> guard(process_launch); // Here I must do something within guard scope // that must be done with the boost::process::launch do_something(); child = boost::process::launch(exec, args, ctx); } // ... boost::process::status s = child.wait(); // ...

6 6

[Git] Moving beyond arm waving?
by Beman Dawes 09 Feb '11

09 Feb '11

To move discussion of Git beyond the arm waving stage, I'd like to suggest several concrete steps: * Use the tag "[git]" to identify list postings discussing integration of Git into Boost daily life. If that gets unwieldy, we can start a separate mailing list. * Start building documentation, with a lot of the initial effort going into rationale and "how to do it". To that end, I've started to populate a "Git" hierarchy on the Trac wiki: https://svn.boost.org/trac/boost/wiki/Git/GitHome. Please contribute! * As a demonstration and proof-of-concept, a Boost library should begin using Git. Presumably a public repository (on GitHub?) can channel changes back to Boost svn. I'll volunteer the filesystem library. Comments? --Beman

28 90

Library proposal: Boost.JniTools - The easy way to call Java methods from C++ (build on top of JNI)
by Boris Brodski 09 Feb '11

09 Feb '11

Hello everyone, I'm the maintainer of the 7-Zip-JBinding project: - On SourceForge: http://sevenzipjbind.sourceforge.net/ - On GitHub: https://github.com/borisbrodski/sevenzipjbinding/tree/RW (Check the RW branch) In order to call C++ code from Java and vice versa the JNI (Java Native Interface) should be used. This interface is low level and provides little safety. (Java VM crashes very easy) Also to get a good performance, a bunch of code is always needed to cache ids and some pointers returned from jni. In the new version of 7-Zip-JBinding (see git RW branch) I wrote a library, that solves some of JNI problems. It uses simple DSL (defines) to describe java classes/interfaces with their methods/fields. It generates from the DSL during pre-compile time some kind of easy to use skeletons around Java classes and interfaces, providing very simple access to their methods and fields. Here are the features: - Type-safe calls from C++ to Java - The compiler will check the number and type of all passed arguments to the called methods. The same applies to setting field. - Caching of method ids and class pointers. - Auto-determining java method signature from the DSL. - Consistent JNI low level error handling - Tools to debug checking and cleaning exceptions after each method call. - Code completion of the java methods and fields from C++ with IDE, capable of expanding defines (for example, with Eclipse CDT). Here is a very simple example, how this library can be used: --- JAVA package test; class MyClass { public long doSomething(boolean param1, int param2, long param3) { ... } } --- C++ (The classic usage of the JNI) jlong callDoSomething(JNIEnv * env, jobject instance, jboolean param1, jint param2, jlong param3) { c = env->FindClass("test/MyClass"); if (!c) { ... handle_error ... } // Writing signatures is annoying jmethodID mid = env->GetMethodID(c, "doSomething", "(ZI)J"); // MethodId should be cached here if (!mid) { ... handle_error ... } // Wrong parameter type/count here cause VM to crash jlong result = env->CallLongMethod(instance, mid, param1, param2, param3); if (env->ExceptionOccurred()) { ... handle_exception ... } env->ExceptionClear(); // Failing to call this method cause VM to crash ONLY IN CASE of exception return result; } --- C++ (Using JniTools) // Describe class. (This could be also generated directly from Java class) JT_BEGIN_CLASS("test", MyClass) JT_CLASS_VIRTUAL_METHOD(Long, doSomething, JT_BOOLEAN(param1, JT_INT(param2, JT_LONG(param3, _)))) JT_END_CLASS jlong callDoSomething(JNIEnv * env, jobject instance, jboolean param1, jint param2, jlong param3) { // with Eclipse CDT: // - the class and method can be auto-completed. // - the parameters can be viewed with the real names (from DSL) // - the return type can be viewed // - "Jump to definition" jumps to the corresponding DSL jlong result = jni::InArchiveImpl::doSomething(env, instance, param1, param2, param3); if (env->ExceptionOccurred()) { ... handle_exception ... } // Failing to call this method cause VM to crash ALWAYS in debug mode // Controlled by define: // JNI_TOOLS_DEBUG_CALL_AND_EXCEPTION_CLEAR_BEHAVIOR jni::expectExceptionCheck(env); return result; } The JniTools library is currently not fully stand-alone. There are some dependencies to other .h files from the 7-Zip-JBinding. Also JniTools doesn't cover all the jni features, that can be covered. The test-coverage of the existing features is however good. Here a some direct links: - The JniTools library: https://github.com/borisbrodski/sevenzipjbinding/blob/RW/jbinding-cpp/JavaS… (has to be renamed) - The usage example: https://github.com/borisbrodski/sevenzipjbinding/blob/RW/jbinding-cpp/JavaS… Tests (called from JUnit): - C++: https://github.com/borisbrodski/sevenzipjbinding/blob/RW/test/CTests/JniToo… - Java: https://github.com/borisbrodski/sevenzipjbinding/tree/RW/test/JavaTests/src… In case, this library has a real chance to become a part of the Boost library, I would be happy to remove all the7-Zip-JBinding dependencies, implement missing features and discuss other possible improvements. It would be match better, if someone will volunteer to help me on this and share the responsibility. Regards, Boris Brodski ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front

3 2

[process] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
by Oliver Kowalke 09 Feb '11

09 Feb '11

I'm missing the possibility to send signals to a process and to wait for a process to be stopped (SIGSTOP) or resumed (SIGCONT) using boost.asio. Oliver

1 0

[spirit.phoenix] Phoenix test coverage
by Jim Bell 09 Feb '11

09 Feb '11

>From names in the spirit regression test matrix <http://www.boost.org/development/tests/release/developer/spirit.html>, I see these four with phoenix in the name: dedent_handling_phoenix, lex_dedent_handling_phoenix, lex_set_token_value_phoenix, set_token_value_phoenix. When I search for phoenix in all libs/spirit/test code, I see references in 104 files, so tests span more than just above four. But how well do phoenix's tests span its content? Is this documented somewhere? Thanks in Advance, -Jim

5 12

Preliminary review request for (Boost) QVM
by Emil Dotchevski 08 Feb '11

08 Feb '11

This is a library for working with Quaternions, Vectors and Matrices of static size. A type traits system is used to enable generic namespace-scope (operator) function templates that implement various Q, V and M operations for any (user-defined) compatible type. The library also defines view proxies which provide lvalue or rvalue access to objects as if they are of a different type. For example, col<1>(m) refers to column 1 of the matrix m as if it is a vector. This system works without creating temporary objects, and should enjoy zero abstraction penalty with most compilers (assuming inlining works.) The online documentation is at http://revergestudios.com/boost-qvm. Complete source code and documentation can be downloaded here: http://revergestudios.com/boost-qvm/boost-qvm.zip. Note: QVM supersedes (Boost) LA which was submitted for preliminary review about a year ago. It adds a few missing pieces (most notably support for quaternions), uses shorter names for types and functions, and is organized into fewer header files. Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 4