- Boost - lists.boost.org

Customer Friendlier Boost Installation
by Paul A Bristow 03 Jun '05

03 Jun '05

Recently we had a flurry of discussion of why Boost is not more widely used. I have used some bits of Boost happily for years, but recently I felt I had to use it 'properly' so concluded it was time I used the bjam build system - something I had felt looked a bit clever. Indeed my suspicion was proved correct - I couldn't get it to work. The instructions are far too Unix/Make oriented for this mere Windows hacker; the Wiki Windows specific instructions are much better but suggest copying (duplicating) a lot of files to avoid an addition to the include directories, and don't apply to the most recent compilers. Victor Wagner gave some hints recently using environment variables, but not the full text. I don't doubt the usefulness of the bjam to the congescenti - only with this could the incredibly impressive build & test system allow all the cracks and chasms of compiler non-compliance and language imprecision to be papered over - Boost's great strength. But if we are to interest your average Windows IDE programmer, for whom MAKE is a blank or a distant nightmare, IMO we need some much better and simpler instructions, including lots of examples of input and output, and to be as well tested as the rest of Boost code. Like it or not, these are the potential customers and I spoken to many who are put off by the 'build barrier'. I suggest that we explicitly say that you can use all of Boost (except the ones that must have built libraries) by adding to the include list - and say exactly how in Windows IDE-ese. If you share my concern, would some someone like to prepare something? Or at least provide details of their way of doing it. I will be willing to help with checking/editing. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

33 194

RE: [boost] Re: Typeof: Review result
by Powell, Gary 03 Jun '05

03 Jun '05

>Meanwhile I am very much puzzled with the inconsistency of rather high >download activity and relatively low amount of feedback the Typeof library >has received on the list. If somebody could offer a reasonable explanation >of this fact, it would help us a lot in our future work with boost. >Best regards, >Arkadiy I suspect its because while a "Typeof" library is very useful, its tedious code to understand. And that's coming from someone who wrote one, with help from Jaakko Jarvi.. (lambda) And I too had intended to at least take a look at this library with the future intent on dropping the internal version in lambda, as I'm sure Joel is too for spirit. However at this time in my life no amount of delay would have helped unless we are talking about 2008.. when I should again have a quieter life. However I will try and give it a once over knowing that any comments are well past the due date. IMO if there are 3 decent reviews then that is probably enough. Still though its a sad state of the world's affairs with a list in the low thousands of users we can't muster more than 3 people with enough time to look at something new and cool. Yours, -Gary-

1 0

yield statement proposal
by Maksym Motornyy 03 Jun '05

03 Jun '05

Hi all, As of version 2.0 C# will have yield statement. It intended for simplifying iterator development. Yield suspends execution of iterator code and resumes it on next increment. Thus complex traversal iterators are much easier to write in natural loop-like form instead of unroll them. Consider following example (C#): public IEnumerator< int > GetEnumerator() { for ( int i = 1; i < 4; ++i ) for ( int j = 1; j < 4; ++i ) yield return i * j; } Such iterator will generate following sequence: 1 2 3 2 4 6 3 6 9. The same code in C++ (using my library) will look like: class simple_generator { public: YIELD_BEGIN_WITH_CTOR( simple_generator, int ) YIELD_FOR_0( i = 1, i < 4, ++i ) YIELD_FOR_1( j = 1, j < 4, ++j ) YIELD_RETURN( i * j ) YIELD_END_FOR_1 YIELD_END_FOR_0 YIELD_END private: int i; int j; }; int main( int, char ** ) { for ( simple_generator g; !g.at_end(); ++g ) cout << *g << " "; return 0; } Have a look at few more examples: Example 1: YIELD_BEGIN_WITH_CTOR( simple_generator, string ) YIELD_RETURN( "Hello," ) YIELD_RETURN( "world!" ) YIELD_END Will print "Hello, world!" in two iterations with the above main() function. Example 2: YIELD_BEGIN_WITH_CTOR( simple_generator, int ) YIELD_FOR( i = 0, i < 10, ++i ) YIELD_IF( i % 2 == 0 ) YIELD_CONTINUE YIELD_END_IF YIELD_RETURN( i ) YIELD_END_FOR YIELD_END Will print "1 3 5 7 9 ". If anyone interested in such thing? Sincerely yours, Maksym Motornyy.

7 12

An interpreter: useful proposal?
by Daniel Gutson 03 Jun '05

03 Jun '05

Hi there, I'm developing an interpreter library support for a project, and I was wondering whether this could be of any help out there. Would it be useful? It provides some structured basic facilities, such as variables, l- and r-values, expressions, functions, subroutines, nested statements, but no object orientation yet. Please let me know whether it's worth the effort to share it here! (since there's still some work to be done :) ). Rgds, Daniel.

1 0

[date_time] CW-9 failures.
by Rene Rivera 03 Jun '05

03 Jun '05

There are some failures for date_time with CW-9 (and similar errors in CW-8): CW-9.5 on Mac... http://tinyurl.com/bwhsw http://tinyurl.com/93nh4 CW-9.4 on Windows... http://tinyurl.com/75t78 http://tinyurl.com/br2b5 CW-8.3 on Windows... http://tinyurl.com/85nf5 http://tinyurl.com/9gfpn They have this as the reason: "[ J. Garland ] Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers." Now I don't particularly think of CW-9 as an "older" compiler. So is that really the reason? Or is it just that it hasn't been investigated? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 3

RE: [boost] Re: yield statement proposal
by Marcin Tustin 03 Jun '05

03 Jun '05

> -----Original Message----- > From: Giovanni P. Deretta [mailto:gpderetta@gmail.com] > Sent: 03 June 2005 03:15 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: yield statement proposal > Speaking of more Boost centric stuff? There has been any > proposal of a coroutine library? I think it should definitely > be useful and not really that hard to implement (fibers on > windows and makecontext or the setjump/sigaltstack trick on > unices). Anyone interested? What about a continuation library? Then co-routines could simply be built on top of that, along with everything else that can be built on top of continuations.

2 1

Template argument deduction question
by Vladimir Prus 03 Jun '05

03 Jun '05

Hello, the program_options library fails one tests on EDG compilers (Intel, Como), which a failure to deduce template arguments for a certain call. After reading the standard for some time, I failed to understand the reason. Below is the test program: char* cmdline3_[1] = {}; template<class charT> void func(const charT* const argv[]) {} int main() { // P is 'const charT* const argv[]'cmdline3_ // A is 'char* cmdline3_[]' // // According to 14.8.2.1/2 // If P is not reference type // -If A is an array type, the pointer type produced // by the array-to-pointer standard convertion (4.2) // is used in place of A for type deduction. // // So, A should become 'char**' // The following does not compile. func(cmdline3_); char** p = cmdline3_; // This does compile, even though the argument type used for // type deduction should be the same as in example above. func(p); } Anybody can explain what's going on? TIA, Volodya

3 4

Probing interest in fixed dimension matrix class
by christopher diggins 03 Jun '05

03 Jun '05

I have just finished writing a fixed dimensionality matrix template (kmatrix<T, Rows, Cols>) which appears to significantly outperform the ublas::matrix. Is there any interest? Below are the results of the benchmarks using Visual C++ 7.1 on an Intel Celeron 1.6 GHZ: Integer matrix multiplication: 2,2 X 2,2 kmatrix 94 msec elapsed ublas 578 msec elapsed 3,3 X 3,3 kmatrix 250 msec elapsed ublas 891 msec elapsed 100,100 X 100,100 kmatrix 593 msec elapsed ublas 1422 msec elapsed 100,1 X 1,100 kmatrix 172 msec elapsed ublas 266 msec elapsed 1,100 X 100,1 kmatrix 625 msec elapsed ublas 1718 msec elapsed Double matrix multiplication: 2,2 X 2,2 kmatrix 94 msec elapsed ublas 593 msec elapsed 3,3 X 3,3 kmatrix 297 msec elapsed ublas 1235 msec elapsed 100,100 X 100,100 kmatrix 766 msec elapsed ublas 1625 msec elapsed 100,1 X 1,100 kmatrix 203 msec elapsed ublas 328 msec elapsed 1,100 X 100, 1 kmatrix 813 msec elapsed ublas 2125 msec elapsed Christopher Diggins http://www.cdiggins.com

8 16

[filesystem] Generic path grammar corner cases
by Beman Dawes 03 Jun '05

03 Jun '05

I'm working to align the Boost.Filesystem generic path grammar with the POSIX specification. Doing so clarifies the specification of the library, and ensures that all native paths for both POSIX and Windows will work correctly. (Windows follows the POSIX conventions in some of the corner cases involved.) The particular cases involve extra slashes in paths. For example, "/foo//bar//". I was surprised to find that such a path is well-defined for POSIX and Windows, with a meaning of "/foo/bar/." In other words, multiple slashes treated as a single slash, and paths with a trailing slash treated as if a period was appended. The rules for more than two leading slashes are a bit more complex - for POSIX they are treated as a single slash, for Windows that is an invalid path. Question: what should path("foo//bar//").string() yield? 1) "foo//bar//" 2) "foo/bar/" 3) "foo/bar/." (1) follows the rule that the path string is always exactly as input. Desirable in that if a platform actually implements something a bit different from the POSIX specs for multiple slashes, implementations will behave as expected for the platform. Downside is much more complex implementation (because many more functions have to be able to cope with multiple slashes) and more complex testing. (2) Desirable in that if a platform actually implements something a bit different from the POSIX (and Windows) specs for multiple slashes, implementations will behave portably and correctly in a POSIX (and Windows) sense. (3) Desirable in that for all three options directory iteration will return three elements - "foo", "bar", "." - so it is a bit counter intuitive for the "." not to appear in the string() results. Not a strong argument. I'm leaning toward (2). Any comments? --Beman

7 12

fusion::for_each question: Why const operator in the fctor?
by Brian Braatz 03 Jun '05

03 Jun '05

I am using the fusion code in 1.32 with the vc 71. compiler. My question is, considering the following unit test (for_each_tests.cpp) struct print { template <typename T> void operator()(T const& v) const { std::cout << "[ " << v << " ] "; } }; { typedef tuple<int, char, double, char const*> tuple_type; tuple_type t(1, 'x', 3.3, "Ruby"); for_each(t, print()); std::cout << std::endl; } (this code runs correctly for me) If I change the function to: struct print { template <typename T> void operator()(T & v) const { std::cout << "[ " << v << " ] "; } }; It still works, but changing it to struct print { template <typename T> void operator()(T & v) { std::cout << "[ " << v << " ] "; } }; Does not work. Why does the functor need to have a const operator()? I have been trying to take a tuple<> and touch each node in the tuple (ala for_each in fusion), which I was *very* happy to find fusion has this as working functionality. But, the next step for me is to have the functor write to its local member variables. I.e. requiring const here really limits the usefulness of the fusion::for_each. I look in my compilers header and noticed that stl::for_each does not have a const requirement on the functor. Is this a mistake? Is there a reason I am not seeing why for_each would have this limitation? Thanks for any help and guidance. Brian "Remember, there are no stupid questions. Only stupid people....."

2 1