- Boost - lists.boost.org

Interest in operator_cast?
by Nick Carroll 12 Feb '09

12 Feb '09

Idea: casting function which invokes an explicitly defined cast operator on a type if defined, else generates a compile-time error. See http://stackoverflow.com/questions/209793/any-way-to-cast-with-class-operat… for discussion of motivation and design. Would there be any interest in incorporating this into boost/cast?

1 0

how to specify options for Boost-building?
by Oliver Kullmann 12 Feb '09

12 Feb '09

Hello, I want to build version 1_38_0, but I can't progress due to missing build-documentation. I need to use bjam (due to special demands on the build), and my platform is Linux. Apparently besides this little bit of information at http://www.boost.org/doc/libs/1_38_0/more/getting_started/unix-variants.html there is nothing available? (Even to get there is not obvious --- you need to click on "microsoft install" first, in order to find a further link to Linux/Unix install?) So well, I invoke "bjam --help": Usage says bjam [options] [properties] [install|stage] where under "properties" we find Properties: toolset=toolset Indicates the toolset to build with. variant=debug|release Select the build variant link=static|shared Whether to build static or shared libraries threading=single|multi Whether to build single or multithreaded binaries runtime-link=static|shared Whether to link to static or shared C and C++ runtime. What's the syntax here?? "--toolset=gcc", as one finds it on that webpage above, or "toolset=gcc", as that information seems to suggest (since for the options the "--" is mentioned)?? Unfortunately, it seems that, different from all other build systems I'm aware of, bjam doesn't print out a summary of what it will be doing. I tried many variations of syntax, but apparently it never worked out. There is an option which is potentially relevant, "--build-type", but again I don't know what are the possible parameters for that --- since there are no examples, I don't know how to read the cryptic listing (syntax-wise). What I need to achieve is simple: 1) I need to specify a locally installed gcc toolset: Past installations suggested to use the options --toolset=gcc-4.1.2 --toolset-root=PATH-TO-LOCAL-INSTALLATION --"-sGCC_ROOT_DIRECTORY=PATH-TO-LOCAL-INSTALLATION" I can't find any information on that topic. 2) I need a local installation of boost; that works out: --prefix=XXX --build-dir=YYY no problem here. 3) No python; this seems also unproblematic (but apparently it vanished from the documentation?) --without-python 4) Only simple names for the built libraries; this seems also to work with --layout=system 5) No multi-threading: Don't know how to achieve this: Somehow "threading=single" seems to be needed here, but I don't know how to specify it (whatever I do, I always end up with libraries with the "mt"-ending). Glad for any help. Oliver

4 7

RFC: interest in Unicode codecs?
by Graham 12 Feb '09

12 Feb '09

Dear Cory, Your UTF standard conversion class looks very interesting. It does however, not give access to the unicode data for grapheme or glyph work. I posted a full unicode character support library at http://www.boostpro.com/vault/ unicode_lib.zip but Rogier and I ran out of time before completing the string class to go with it. If you feel up to it and want to develop a full Unicode support library in addition to your codec, feel free ! Yours, Graham Barnett >Is there interest in having a Unicode codec library submitted to Boost? > >Here is what I have (only tested with GCC 4.3 on Debian, and VC++ 2008): >http://svn.int64.org/viewvc/int64/snips/unicode.hpp > >Right now it is pretty simple to use: > >transcode<utf8, utf16le>(forwarditerator, forwarditeratorend, >outputiterator, traits [, maximum]); >transcode<wchar_encoding, utf32be>(inputrange, outputrange, traits [,maximum]); > >There is also a codecvt facet which supports any-to-any. > >Supports UTF-8, UTF-16, and UTF-32, in little or big endian. Has a >special wchar_encoding that maps to UTF-16 or UTF-32 depending on your >platform. A traits class controls error handling. > >-- >Cory Nelson

1 0

Review Request: Introduction of boost::string namespace and string-conversion functions
by Vladimir.Batov＠wrsa.com.au 12 Feb '09

12 Feb '09

Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string namespace where I'd expect all string-related functionality might be logically housed. Dave already mentioned that "Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space". My immediate interest/proposal in that namespace would be the string-conversion functionality. The basics of that functionality are currently handled by lexical_cast but need extended and unambiguously tagged as *string*-related conversions. During discussion I've got a strong impression that the majority of people, the lexical_cast author (Kevlin) and the maintainer (Alex) strongly favor leaving lexical_cast as-is and having a fresh start capitalizing on the past experiences. Therefore I'd like to propose the string-conversion functionality that'd be housed inside that mentioned boost::string namespace. This proposal of mine probably is not as conventional as I have no implementation code to show. That is because before committing to it any further (or dragging someone else into it) I would initially like to see if we can agree on 1) creating boost::string (or some other as descriptive name) namespace; 2) the interface for that proposed string-conversion functionality. After that I expect the implementation to be largely a technical issue. >From the user point the interface I'd like to propose might look like the following: int i; std::string s; 1) int i_from_s = boost::string::to<int>(s); // throws 2) std::string s_from_i = boost::string::from<int>(i); 3) bool s_is_i = boost::string::is<int>(i); The above convert a string to an integer (#1), an integer to a string (#2) and check if conversion is possible (#3). #1 and #2 behave like lexical_cast currently does (throw on failure). #3 is a non-throwing check if #1 will succeed (to avoid handling an exception thrown by #1). For example, int i_from_s = boost::string::is<int>(s) ? boost::string::to<int>(s) // safe to request conversion : some-failure-value; I like to/from names as they allow me to read the code as it was merely English -- "string to int", "string from int". I expect string::to() and string:;from() to return a helper object as Dave suggested namespace string { template <class T> struct value { operator T() const; // throws iff parse unsuccessful bool good() const; // true iff parse will succeed ... }; } That'll allow as to make the interface consistent and extendable/chainable: 4) int i_from_s = boost::string::to<int>(s)(-1); The above is a non-throwing variation of #1 with the default value provided for failed conversion. 5) int i_from_s = boost::string::to<int>(s)(std::hex); 6) std::string s_from_i = boost::string::from<int>(i)(std::hex); The above is variations of #1 and #2 with the std::hex manipulator/formatter applied. That "chained" approach would allow to keep the interface consistency without sacrificing the flexibility. For example, 7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator); or add some other features when the need arises. Off the cuff the actual conversion might look something along the following lines: template<class T, class Char> boost::string::value::operator T() { std::basic_istringstream<Char> stream(string_); if (manipulators) stream >> manipulator_ >> ... >> value_; else stream >> value_; if (stream.fail()) if (no_default) throw something; else return default_value_; return value_; } Thanks, Vladimir.

12 19

[future] @Tom -> review result?
by k-oli＠gmx.de 12 Feb '09

12 Feb '09

Hello, as Vicente lready ask - what is the result of the future review?! @Tom could you confirm that you are still working on the review summary? Oliver

1 0

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20

[trac] Type of ticket: "Bugs", "Patches", or "Feature Requests"?
by Niels Dekker - mail address until 2010-10-10 12 Feb '09

12 Feb '09

https://svn.boost.org/trac/boost/newticket has a Type dropdown-list that has "Bugs" as default. When my report has a patch file attached, should I set the Type to "Patches" instead? If fact, the report I have in mind is mainly a performance issue. I would like boost::array::swap to internally call boost::swap, instead of std::swap_ranges, mainly because some C++03 implementations of std::swap_ranges exchange the elements by doing element-wise copy operations, even when there is a custom swap for the element type. The new boost::swap utility takes care of calling the appropriate custom swap, whenever found by argument-dependent lookup (ADL). My report will have a patch. So is the type of such a report considered a "Feature Request", a "Bug", or a "Patch"? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 2

Re: [boost] [log] Review-ready version in the Vault
by Vladimir.Batov＠wrsa.com.au 12 Feb '09

12 Feb '09

Andrey, Thank you for your contribution. I do not think I'll be participating in trial-runs or review as such. However, I read through the documentation and looked at the interface and I thought I'll give you my first (well, second, I looked at your lib. before) impression. I realize that everyone probably has something to say about logging and such a debate can get hot. So, I want to say beforehand that my reply is merely my impression (not a review or criticism of any kind). Firstly, it certainly seems very rich in features and configurable. That is certainly a huge plus for such a library as logging. However, I was truly overwhelmed by the documentation, the interface and the deployment examples. I seemed to be reading about familiar concepts -- severity levels, sinks, filters, formatters, streams/channels. However, after all that I did not feel an inch closer to actually deploying your library. I consider myself a moderately intelligent person but the seeming complexity felt quite intimidating. Somehow other implementations I read about (J.Torjo's, log4cpp, log4j, a bunch of loggers at SourceForge) went down much easier. Roughly, as a user I'd expect something as straightforward as boost::log log(name); // Create a log boost::log::sink sink = boost::log::sink(file)(stdout)(event_log); // Set up sinks boost::log::formatter fmt = boost::log::formatter(date)(thread_id)(name); // Set up the formatter boost::log channel = log.channel(channel-name); // Create a channel log(sink)(fmt); // Associate sinks and formatting if (log) log << "Hello, main world"; if (channel) channel << "Hello, channel world"; Maybe that's what your interface does. I just did not get that warm and fuzzy easiness/familiarity feeling after reading the docs and looking at the deployment examples. I feel there is a considerable room for improvement here. In particular I was left puzzled how you actually create a log instance (I think in the docs it is boost::src::logger). I'd expect to be able to create a log instance with a name and to be able to retrieve that same instance by the name anywhere in the program. That is, boost::log log1(name); boost::log log2(name); would be referring to the same log instance (pointer semantics). That'd be very liberating. Best, Vladimir.

8 18

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[TR1] Problems with TR1 include paths with Mingw?
by Richard Webb 12 Feb '09

12 Feb '09

Hi, I've got some code that i've been building with MSVC that uses the TR1 lib by adding the boost/tr1/tr1 dir to the include path, which i'm now trying to build using Mingw/msys. It seems to build ok using the code on the release branch, but using the current trunk i get: d:/Boost/BoostSVN/boost/tr1/detail/config_all.hpp:162:41: error: ../4.3.2/utility: No such file or directory Am i doing something silly, or have the recent changes to the include logic broken something for Mingw? For reference, i'm using the GCC 4.3.2 build from http://www.tdragon.net/recentgcc/ Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-TR1--Problems-with-TR1-include-paths-with-Mingw--tp2… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2