- Boost - lists.boost.org

mpl::for_each and polymorphic function object
by Gennadiy Rozental 23 Feb '04

23 Feb '04

Hi, I found following issue: if I have const type in a list of types test case template facility initialized with, it really gets instantiated with non const type. After some investigation I found the reason. The reason is the mpl::for_each, used in the facility implementation, rely on type deduction based on type of single argument it passes. It works for simple function and function object. But it does not for function object with template operator(). It's all originated from the fact that following code compiles: struct { template<typename T> void operator()( T ) { T t = 0; ++t; } } foo; int main() { char const x = 0; foo( x ); return 0; } because foo.operator() is instantiated with type char - not char const. Is the any workarounds? Could we fix that? Gennadiy. P.S. Actually I was concerned with this unused parameter from the very beginning. It prohibit using for_each with types without default constructor and also could be source for performance problems. Could we eliminate this unused parameter at all?

2 2

Re: [boost] [mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY
by Aleksey Gurtovoy 22 Feb '04

22 Feb '04

Jonathan Turkanis wrote: > I was having a bit of trouble this afternoon getting some MPL code to > compile, when I realized I was trying to use a placeholder symbol > embedded in an expression using a metafunction of arity 7. I know that > the maximum metafunction arity is set at 5, so I tried setting > BOOST_MPL_METAFUNCTION_MAX_ARITY to 7. This didn't work either, > because of the preprocessed headers. So I tried defining > BOOST_MPL_NO_PREPROCESSED_HEADERS. This reduced the number of error > messages from infinity to 27. > > So I have these questions: > > 1. Am I right that as presently configured mpl::lambda cannot look for > placeholders inside (fully-curried) metafunctions of arity > 5? Yes. You either need to regenerate preprocessed headers for the new configuration, or to go with BOOST_MPL_NO_PREPROCESSED_HEADERS. > 2. Are preprocessed headers used just to cut compilation times, or for > some more fundamental reason? The former, and also to workaround a bug present in old EDG front-ends. > If it is just to save time, how much > time does it save? IIRC, it makes a noticeable difference for EDG-based compilers (10-20%, I think), and not so noticeable for others (< 5%). It's been a long time since I did the measurements, so chances are things changed since then. It's always safe to do the comparison yourself, just to be sure :). > 3. Is there any way to circumvent the preprocessed headers entirely to > compile mpl with a different max arity? Defining BOOST_MPL_METAFUNCTION_MAX_ARITY together with BOOST_MPL_NO_PREPROCESSED_HEADERS the should do it. If not, it's a bug. I'll check if that's the case with the current CVS state. -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

request: tokenizer documentation
by Bronek Kozicki 22 Feb '04

22 Feb '04

It would be nice if tokenizer documentation clearly explains that tokenizer constructor is not making a copy of its input data, thus passing temporary value as first argument to its constructor invites undefined behaviour. Following code can be given as an example of such undefined behaviour: #include <string> #include <iostream> #include <boost/tokenizer.hpp> using namespace std; using namespace boost; int main() { typedef tokenizer<char_separator<char>, string::const_iterator, string> Tokenizer; const char_separator<char> semicolon(";"); Tokenizer tokens(std::string("a;b;c"), semicolon); string t("x;y;z"); for (Tokenizer::const_iterator i = tokens.begin(); i != tokens.end(); ++i) std::cout << *i << std::endl; } (program may produce different output depending on compiler and its options, or simply crash) B.

1 0

Re: [boost] Re: algorithms namespace
by Dave Gomboc 22 Feb '04

22 Feb '04

> >>We can (re-)consider 'boost::meta': > >> > >>Doesn't look bad at all, actually. > > > > I'm a big fan of using "meta" instead of "mpl". > > FWIW, I'm not. I type it often enough to be bothered by the > completely unnecessary extra character. And I'd prefer boost::metaprogramming, but I'll settle for meta if it's the best that I can get. ;-) Human languages are full of "extra characters": why should programming languages be different in this respect? If the typing truly bothers you, try out an editor that supports word completion. fs is arguably sufficiently common, but I still prefer filesystem. Not all that long ago someone posted something here and abbreviated it as "rng", and I thought to myself that it was very odd that they'd use something that, as far as I am concerned, abbreviates "random number generator". On the flip side, perhaps if I had referred to one of these as "rng" they would be thinking the converse. Ergo, prefer filesystem: those who want it shorter probably don't want the boost:: part either, and will define fs = ::boost::filesystem once and use four characters (fs::) from there on. Besides which, "fs" is difficult for an English-as-a-second-language speaker to look up in the dictionary. I have the impression that some simply don't care about that because English is _their_ first language -- an unfortunate attitude. Last year I vistied Slovenia, and when I said "standard-eye-oh-dot-aitch" to some people, they didn't understand me, and asked what I was talking about. After some discussion back and forth, it turns out that they spell that header name out character by character: "s-t-d-i-o-pika-h". (pika = dot, and all the letters are pronounced differently too, of course.) They had no idea that "std" was being used as an abbreviation for standard in this context. "So 's-t-d' means standard?" "Yes... how do you say standard in Slovene?" "Standardija." (!) This demonstrates that even small differences for us can be huge differences for others. It turns out that the "i-o" for input/output doesn't translate well into Slovene, so those person (and all their programming friends, I'm sure) are now happily calling it "standardija-i-o-pika-h", something I'm sure most readers of this message will have taken the English equivalent of for granted since the first week they programmed in C. Had "standard" been used instead of "std", this confusion would never have arisen, but more importantly the name would have been meaningful to more people. Re: boost::algorithm::<subnamespaces>, it's easy to add using directives to bring things defined in these up to boost::algorithm. The opposite operation is not easy. If it turns out do be better to have them all together, using declarations can be added to boost itself down the road. Dave P.S. I think that the average teenager probably has a different meaning for 'std' than we do too, though I'll grant that that's less relevant. ;-)

8 7

Nightly CVS docs
by David Abrahams 22 Feb '04

22 Feb '04

The "Nightly CVS" link on the home page doesn't take you to our full documentation. Instead it points at the generated docs at meta-comm for whatever subset of Boost libraries that applies to. Doesn't seem right to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[Filesystem] Notes for Cygwin users
by Beman Dawes 22 Feb '04

22 Feb '04

The Cygwin environment is special in that it supports both the native Windows API's and Linux/POSIX emulation API's. The default for Boost.Filesystem builds is to treat Cygwin environment as native Windows. Some Cygwin users would prefer the Linux/POSIX emulation. Boost.Filesystem has now been tested in both Cygwin environments. No changes were required in the 1.31.0 or current CVS head implementation code. Two of the test programs have been changed in CVS to make testing both Cygwin environments easier. The docs in CVS have been updated with the following "Notes for Cygwin users": The library's implementation code automatically detects the current platform, and compiles the POSIX or Windows implementation code accordingly. Automatic platform detection during object library compilation can be overridden by defining BOOST_POSIX or BOOST_WINDOWS macros. With the exception of the Cygwin environment, there is usually no reason to define one of the macros, as the software development kits supplied with most compilers only support a single platform. The Cygwin package of tools supports traditional Windows usage, but also provides an emulation layer and other tools which can be used to make Windows act as Linux (and thus POSIX), and provide the Linux look-and-feel. GCC is usually the compiler of choice in this environment, as it can be installed via the Cygwin install process. Other compilers can also use the Cygwin emulation of POSIX, at least in theory. Those wishing to use the Cygwin POSIX emulation layer should define the BOOST_POSIX macro when compiling the Boost Filesystem Library's object-library. The macro does not need to be defined (and will have no effect if defined) for Boost Filesystem Library user programs. --Beman

1 0

Status
by agurtovoy＠meta-comm.com 22 Feb '04

22 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

value_initialized and msvc6.5
by Gennadiy Rozental 22 Feb '04

22 Feb '04

I couldn't compile following code with msvc 6.5. #include <boost/utility/value_init.hpp> boost::value_initialized<char const> c; Others compilers seems to be ok. Any pointers? Gennadiy. P.S. Error message: ...boost/utility/value_init.hpp(29) : error C2758: 'x' : must be initialized in constructor base/member initializer list ...\boost/utility/value_init.hpp(31) : see declaration of 'x' ...\boost/utility/value_init.hpp(29) : while compiling class-template member function '__thiscall boost::vinit_detail::const_T_base<char const >::boost::vinit_detail::const_T_base<char const >(void)' P.P.S. But it does present in member initializer list??!! const_T_base() : x() {}

1 0

[mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY
by Jonathan Turkanis 21 Feb '04

21 Feb '04

I was having a bit of trouble this afternoon getting some MPL code to compile, when I realized I was trying to use a placeholder symbol embedded in an expression using a metafunction of arity 7. I know that the maximum metafunction arity is set at 5, so I tried setting BOOST_MPL_METAFUNCTION_MAX_ARITY to 7. This didn't work either, because of the preprocessed headers. So I tried defining BOOST_MPL_NO_PREPROCESSED_HEADERS. This reduced the number of error messages from infinity to 27. So I have these questions: 1. Am I right that as presently configured mpl::lambda cannot look for placeholders inside (fully-curried) metafunctions of arity > 5? 2. Are preprocessed headers used just to cut compilation times, or for some more fundamental reason? If it is just to save time, how much time does it save? 3. Is there any way to circumvent the preprocessed headers entirely to compile mpl with a different max arity? Jonathan

1 0

Re: algorithms namespace
by Robert Ramey 21 Feb '04

21 Feb '04

I've followed this discussion for a while hoping it would just go away. Well I can't stand it any more - here's my 2 cents. Keeping names in my head is a big problem. So I don't like making any more names than necessary. I'm not crazy about abbreviations either - it's one more thing to remember. Of course if its one or two it wouldn't be a big deal but once it starts it tends to spread. I do like analogies: STL -> RTL -> VTL -> MPL Help me remember things. I'm aware this is probably not the motivation of the authors but none the less it helps me remember. In a short context ( within a code file ) if I get tired of typing, I will use a LOCAL alias e.g. Using namespace fs = boost::filesystem - or whatever the correct syntax is. But a global one - used everywhere is one more thing I have to remember everywhere. It's a bad idea. It's the same problem as global variables - as boost gets bigger I can't keep it all in my head at once. I don't like to do a lot of work for almost no good purpose - changing mpl to meta through a lot of already written code would be a huge waste of time at best and a big pain at worst - does anyone know for a fact that meta wouldn't clash with something? Is it even worth the time to check? The following two are important to me also - though I don't know whether anyone has proposed that they be abandoned. I much like the current practice of having the namespace hierarchy parallel the file directory hierarchy. This should be maintained at all costs. Its just another waste of global brain capacity to try to maintain two such hierarchies in ones head. I think its very valuable that one library/maintainer correspond to a namespace. In short, I don't think any changes in this area would be anything but detrimental. Robert Ramey

1 0