- Boost - lists.boost.org

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

23 Feb '04

> Well. It's actually the opposite. Because English is > (presumably) your first language, you prefer the > non-abbreviated "filesystem" over "fs". From the perspective > of someone who doesn't "think in English", the two have > pretty much the same inherent value, i.e. they are arbitrary > identifiers. >From the perspective of this English-speaking software developer, I recognize filesystem, and I also know what fs means. Furthermore, the first time I hear "fs", I imagine that I was able to guess from the context it was used in that fs means filesystem. >From the perspective of a developer who knows English but whose native tongue is not English, filesystem is understandable, because the component words, file and system, either are known or are looked up in a translation dictionary. "fs", on the other hand, is incomprehensible without supporting documentation. > A mental mapping translates these identifiers > into the entities they represent. Since the extra letters in > the longer identifier do not add any semantic value to > non-English speakers, they are merely clutter and do not > contribute to readability. You're missing the point -- the extra letters *do* add semantic value to those who speak English, but not as a first language. > Your observation that "stdio" is a _word_ in non-English > programmer cultures, and not an abbreviation of "standard > input/output", is very much in line with the above. Stdio was *not* a word to them, it was just a jumble of random characters. The whole concept of "standard" had been lost! Dave

2 1

Re: [boost] Re: mpl::for_each and polymorphic function object
by Aleksey Gurtovoy 23 Feb '04

23 Feb '04

Gennadiy Rozental wrote: > > mpl::for_each<mpl::transform<s, wrap<_1> >::type>(foo()); > > I saw this in mpl::for_each test. Actually, if you do it as in the test, it's even simpler: mpl::for_each< types,wrap<_1> >(foo()); > It may probably solve my problem. But is tyhe more generic solution? Sorry, cannot parse this one. > Or why doesn't for each pach mpl::identity in a first place? Sometimes the value semantics is exactly what you want: typedef mpl::range_c<int,0,10> numbers; std::vector<int> v; mpl::for_each<numbers,mpl::_>( boost::bind(push_back, &v, _1) ); > Or could we eliminate parameter at all and make for_each to > work with explicit type specialization, like this: > > aux::unwrap(f, 0)::operator()<arg>(); Like the previous suggestion, it would rule out ordinary function objects; besides, it's not portable. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 23 Feb '04

23 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > > // A strange way to retrieve my_container.begin(): > boost::prior( my_container.end(), my_container.size() ); > > Is that legal? The second template parameter of boost::prior > is deduced > to an unsigned(!) type, which IMHO means that -n is > undefined, right? Do > we need to fix this? It's both legal and well defined, but perhaps not very intuitive... For unary minus, the negative of an unsigned is computed as 2^n-v (where n is the number of bits in the type yielded by performing integral promotion on the operand and v is the value of the operand [5.3.1/7]). The resulting type is the promoted operand; this means that unsigned char and unsigned short will typically work as expected with boost::prior (those types can be promoted to int on most [all?] platforms), whereas unsigned int and unsigned long will always return a positive value (because here, the resulting type of integral promotion is the type of the operand, and the result of the unary - operator is therefore 2^n-v). So, the effect of this is that the example above is valid, but the resulting iterator is past-the-end, typically way too far to ever be seen again...and the name 'prior' thus becomes misleading for certain types. > or shall we document that it's illegal/undefined to call > boost::prior() > with an unsigned second parameter? I think Dave's suggestion of using reverse_iterator would be cool; that also adds a good reason for using boost::prior rather than std::advance for decrementing. Something like this should work: template <class T, class Distance> inline T prior(T x, Distance n) { return next(std::reverse_iterator<T>(x),n).base(); } (Daniel, good work spotting this issue!) Bjorn Karlsson

2 1

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

23 Feb '04

Jonathan Turkanis wrote: > > 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. > > Thanks. FYI I got the errors with VC7.1. These were caused by a hard-coded 'bind' specialization in the "if.hpp" header. The code fails only if you disable the preprocessed headers _and_ reconfigure the arity, while the usual testing procedure was to test only with BOOST_MPL_NO_PREPROCESSED_HEADERS, and that's why the regression hasn't been caught earlier. Fixed in the main trunk. Thanks for reporting it, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

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