- Boost - lists.boost.org

[bind] Patch that enables pass-by-value
by Lars Rune Nøstdal 16 Jun '04

16 Jun '04

Hi, I'm a new user of this library, so not sure if this is a good idea or the best way to do this. void f(int x) { cout << "f(int): " << x << endl; } int x = 0; bind(f, _1)(x); //bind(f, _1)(1); // Does not work. bind(f, _1)(val<int>(1)); // But this does after patching. This enables the user to pass-by-value if he specifies it explicitly, here is the patch: Index: boost/bind.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind.hpp,v retrieving revision 1.36 diff -u -c -d -r1.36 bind.hpp *** boost/bind.hpp 8 Jun 2004 13:43:03 -0000 1.36 --- boost/bind.hpp 15 Jun 2004 19:13:43 -0000 *************** *** 27,32 **** --- 27,33 ---- #include <boost/type.hpp> #include <boost/bind/arg.hpp> #include <boost/detail/workaround.hpp> + #include <boost/val.hpp> // Borland-specific bug, visit_each() silently fails to produce code Index: boost/bind/bind_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind/bind_template.hpp,v retrieving revision 1.4 diff -u -c -d -r1.4 bind_template.hpp *** boost/bind/bind_template.hpp 7 Mar 2004 16:39:15 -0000 1.4 --- boost/bind/bind_template.hpp 15 Jun 2004 19:13:43 -0000 *************** *** 27,32 **** --- 27,38 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1> result_type operator()(val<A1> a1) + { + list1<A1> a(a1); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1> result_type operator()(A1 & a1) { list1<A1 &> a(a1); *************** *** 39,44 **** --- 45,56 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2> result_type operator()(val<A1> a1, val<A2> a2) + { + list2<A1, A2> a(a1, a2); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2> result_type operator()(A1 & a1, A2 & a2) { list2<A1 &, A2 &> a(a1, a2); *************** *** 51,56 **** --- 63,74 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3) + { + list3<A1, A2, A3> a(a1, a2, a3); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3> result_type operator()(A1 & a1, A2 & a2, A3 & a3) { list3<A1 &, A2 &, A3 &> a(a1, a2, a3); *************** *** 63,68 **** --- 81,92 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4) + { + list4<A1, A2, A3, A4> a(a1, a2, a3, a4); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4) { list4<A1 &, A2 &, A3 &, A4 &> a(a1, a2, a3, a4); *************** *** 75,80 **** --- 99,110 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5) + { + list5<A1, A2, A3, A4, A5> a(a1, a2, a3, a4, a5); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5) { list5<A1 &, A2 &, A3 &, A4 &, A5 &> a(a1, a2, a3, a4, a5); *************** *** 87,92 **** --- 117,128 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6) + { + list6<A1, A2, A3, A4, A5, A6> a(a1, a2, a3, a4, a5, a6); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6) { list6<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &> a(a1, a2, a3, a4, a5, a6); *************** *** 99,104 **** --- 135,146 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7) + { + list7<A1, A2, A3, A4, A5, A6, A7> a(a1, a2, a3, a4, a5, a6, a7); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7) { list7<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &> a(a1, a2, a3, a4, a5, a6, a7); *************** *** 111,116 **** --- 153,164 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7, val<A8> a8) + { + list8<A1, A2, A3, A4, A5, A6, A7, A8> a(a1, a2, a3, a4, a5, a6, a7, a8); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7, A8 & a8) { list8<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &, A8 &> a(a1, a2, a3, a4, a5, a6, a7, a8); *************** *** 123,128 **** --- 171,182 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7, val<A8> a8, val<A9> a9) + { + list9<A1, A2, A3, A4, A5, A6, A7, A8, A9> a(a1, a2, a3, a4, a5, a6, a7, a8, a9); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7, A8 & a8, A9 & a9) { list9<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &, A8 &, A9 &> a(a1, a2, a3, a4, a5, a6, a7, a8, a9); *** /dev/null Thu Jan 1 01:00:00 1970 --- boost/val.hpp Tue Jun 15 22:00:29 2004 *************** *** 0 **** --- 1,35 ---- + #ifndef BOOST_VAL_HPP_INCLUDED + #define BOOST_VAL_HPP_INCLUDED + + // val.hpp - Usefull helper functions + // + // Copyright (C) 2004 Lars Rune Nøstdal (larsnostdal(a)organizer.net) + // + /* + Distributed under the Boost Software License, Version 1.0. + (See accompanying file LICENSE_1_0.txt or copy at + http://www.boost.org/LICENSE_1_0.txt) + */ + + + namespace boost { + + template<typename T> + struct val { + val(T t) + :value(t) + { + } + + operator T&() + { + return(value); + } + + private: + T value; + }; // val + + } // namespace boost + + #endif // #ifndef BOOST_VAL_HPP_INCLUDED Thanks, Lars Rune Nøstdal

3 3

[tuple] problem with global tuples::get() in vacpp 6.00
by Joaquín Mª López Muñoz 16 Jun '04

16 Jun '04

Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking Boost.MultiIndex and a test of Boost.Iterator. Please find below a very simple and totally conformant fix. This has not actually been tested with vacpp, but I checked it does not break anything with some other compilers. 1. Could anybody check locally if this solves the aforementioned problems in vacpp? 2. If 1 is positive, can I commit this to the CVS? Anyone sees a problem? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo **************DIFF************** 201c201,203 < >::non_const_type>(c); --- > >::non_const_type, > HT,TT > >(c); 216c218,220 < >::const_type>(c); --- > >::const_type, > HT,TT > >(c);

4 11

Geometric Algebra Library
by Jaap Suter 16 Jun '04

16 Jun '04

Hi, This is a follow-up to my original email from June 9th, see: http://tinyurl.com/3defq [again crossposted to oo-numerics and boost-developers] After this email, several people expressed interest in my geometric algebra library. Unfortunately I cannot address each email individually, so thanks to everybody that replied. First, I want to introduce a new feature I added this week.. It's what I like to call the "auto_element" feature. Within the Clifford framework it works like a "typeof" or "auto" feature. Consider the following: typedef algebra<float, 4, 1> conformal_space; element<list_c<int, 0, 2>, conformal_space> a; element<list_c<int, 1, 2, 4>, conformal_space> b; some_type c = left_contraction(a, b) * outer_product(some_vector, some_bi_vector); People familiar with Clifford algebra know that sometimes it is hard to decude what grades appear in the resulting element of a complicated expression. E.g., in the above example, who can tell me what grades appear in the left_contraction of a conformal-spinor and an element that has grade 1, 2 and 4. Let alone if you multiply that with the outer_product of some vector and some bivector. In other words, what is the type of c? Most other libraries solve this by just using a full multivector (consisting of 32 floats) in this case, which is often redundant. In fact, perhaps the above expression results in just a single scalar. That's a lot of calculation and storge for just one number then. This library allows you to write: auto_element(conformal_space, c, left_contraction(a, b) * outer_product(some_vector, some_bi_vector) ); [indention weird, because of the line-ending limit] which will declare an multi-vector of a type that contains the bare-minimum of grades necessary to capture all the information available in the expression. This has big performance improvements, but more interesting, it makes generic programming with arbitrary elements of an algebra a lot of fun. You don't have to know what types are involved in an expression anymore, but still get all the benefits of static type-checking and the associated performance analysis. Who said C++ was statically typed? :) By the way, for those wondering how I did it, obviously auto_element is a macro that does some (compile-time) stuff. It's not that hard, but a technique I hadn't seen before (let me know if it does exist somewhere else, or if there's a better way of doing this). Come to think of it, other libraries that involve dimensional-types (matrix libraries, etc.) could possible benefit from this as well. Anyway, enough about that... I have now uploaded a package to http://www.jaapsuter.com containing all the header files, some of my unit-tests, and the MSVC 7.1 project file. For reasons outside of my control I cannot upload all of the unit-tests yet. This will be resolved shortly. If you consider porting this to GCC, I would still recommend trying to compile the project in MSVC first and play around with it. It's some really heavy code internally. Hopefully (this is for you to judge) the client-side (see the unit-tests) are very friendly though. So please browse the tests before you dive into the implementation. Comments are welcome. There is still some bugs with certain expressions (as a consequence of not being able to deal with unsorted grade-lists), this will be fixed shortly. I am working on the library on-going, but I am hoping somebody will join. Then, somebody mentioned the interoperability with std::complex and Hubert Holin's Quaternion and Octonion library. I have some tests that test whether Clifford and these libraries behave the same (and inter-operate). As for implementing these types in terms of a geometric algebra? It depends. Sometimes it's worthwhile to specialize and keep things simple (think about scoped_ptr not being implemented in terms of a policy_ptr). But then again, if you have a clifford library in your project already anyway, you might as well use it for complex numbers, quaternions, etcetera. Otherwise, using clifford to provide these basic components is probably overkill. Regards, Jaap Suter

2 1

Geometric Algebra Library
by Jaap Suter 16 Jun '04

16 Jun '04

Hi, [crossposted to oo-numerics and boost-developers] About 20 months back, I asked if there was any interest in a geometric or Clifford algebra library written in C++. Despite some positive replies, I got the impression that there were not a lot of people in the Boost community who saw any practical uses for such library. Back then I had a rudimentary proof-of-concept for a Clifford algebra library that used meta-programming techniques to gain significant performance benefits over other existing libraries (Gaigen, nKlein, CLU, etcetera). Over the past few months I have put a lot more work into this library. The bulk of the work consisted of adding more unit-tests, proving many of the theorems in some of the papers by David Hestenes et al. I also added expression templates to improve performance. To give an idea of what the library is capable of: #include <boost/math/clifford/clifford.hpp> #include <boost/mpl/list_c.hpp> #include <cassert> using namespace boost::math::clifford; using namespace boost::mpl; typedef algebra<4, 1> conformal_model; typedef blade<float, 0, conformal_model> scalar; typedef blade<float, 1, conformal_model> vector; typedef blade<float, 5, conformal_model> pseudo_scalar; typedef blade<float, 2, conformal_model> bi_vector; // same as: // typedef element<float, list_c<int, 1>, conformal_model> bi_vector; typedef list_c<int, 0, 2> spinor_grades; typedef element<float, spinor_grades, conformal_model> spinor; typedef list_c<int, 0, 1, 2, 3, 4, 5> multi_vector_grades; typedef element<float, multi_vector_grades, conformal_model> multi_vector; int main() { assert(sizeof(scalar) == sizeof(float)); assert(sizeof(vector) == 5 * sizeof(float)); assert(sizeof(bi_vector) == 10 * sizeof(float)); assert(sizeof(pseudo_scalar) == sizeof(float)); assert(sizeof(spinor) == 11 * sizeof(float)); assert(sizeof(multi_vector) == 32 * sizeof(float)); vector e_plus; e_plus[3] = 1.0; vector e_min; e_min[4] = 1.0; e_star = e_min - e_plus; e_star *= -std::sqrt(2.0); e_star /= 2.0f; e [noalias] = e_plus * std::sqrt(2.0) - e_star; bi_vector E = outer_product(e, e_star); // geometric product between bi_vector and vector multi_vector v = E * e_star; // geometric product between two vectors, generating a spinor vector a, b; spinor s = a * b; // doing a spinor rotation vector c; c [noalias] = reverse(s) * a * s; } Each product always does the bare minimum of additions, multiplications and subtractions to calculate the result on the left-hand-side of an expression. Thus, if you do the full geometric product of two multi_vectors but assign it to a scalar, it will only do those calculations that are involved in grade 0. Also, unlike other existing libraries, no dynamic allocations are being done ever. Currently, the following operations are supported, between any two random elements of an algebra (blades and composite multi_vectors): geometric_product = operator * inner_product outer_product fat_dot_product left_contraction right_contraction scalar_product of course, all the normal operations (scalar multiplication, addition of elements, etcetera) are supported, as well as reversion, involution and conjugates. Adding more operators is trivial. They can either be implemented in terms of existing operators, or by implementing an appropriate grade-predicate. For example, this is what the implementation of the outer_product looks like: struct outer_product_predicate { template <class ResultGrade, class LhsGrade, class RhsGrade> struct apply { typedef typename mpl::if_ < typename mpl::equal_to < ResultGrade, typename mpl::plus<LhsGrade,RhsGrade>::type >::type, mpl::true_, mpl::false_ >::type type; }; }; BOOST_MATH_CLIFFORD_PRODUCT_IMPL( outer_product, impl::outer_product_predicate ) which for somebody that knows the definition of the outer_product is easy to understand. I have unit-tests for 2, 3 4 and 5 dimensional algebras, but more is possible if your compiler supports it. Currently I have only tested the library on MSVC 7.1. I tried 7.0 but couldn't get it to work (excessive use of MPL). GCC and Intel compiled it at one point, but because I only use MSVC I dropped support. Of course, if anybody is interested I'd be trying other compilers again. You will need a compiler that does aggresive inlining though. On MSVC I am using the force_inline feature to get the release performance I need. Anyway, let me know if anybody is interested, and I'll put together a package to upload somewhere. Cheers, Jaap

7 6

[Boost-bugs] [ boost-Support Requests-973424 ] boost::optional<enum> fails with /CLR
by SourceForge.net 15 Jun '04

15 Jun '04

Support Requests item #973424, was opened at 2004-06-15 11:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=973424&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::optional<enum> fails with /CLR Initial Comment: ----- #include <boost\optional.hpp> #using <mscorlib.dll> #include <tchar.h> using namespace System; enum Numbers { Zero, One, Two, Three }; // This is the entry point for this application int _tmain(void) { boost::optional<Numbers> num; return 0; } ----- optional.hpp(347): error C2300: 'System::Enum' : class does not have a destructor called '~T' I'm using boost 1.31.0; this fails in both VC7.0 and VC7.1. Removing "#using <mscorlib.dll>" and "using namespace System;" gets rid of the compiler error, but then you can't use things like System::String* Thanks, Dan sourceforge.net(a)jdanielsmith.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=973424&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Announcing a New C++ Zine
by Chuck Allison 15 Jun '04

15 Jun '04

brlbo> This is very impressive, but from the standpoint of the reader it brlbo> appears very much to be a direct competitor to CUJ's Experts' Forum. Do brlbo> you think there is room for both initiatives? Don't get me wrong, I do brlbo> hope there is, but I'm afraid there might not be. brlbo> Cheers, brlbo> Nicola Musatti If you look at the members of the Editorial Board, please keep in mind that we all have been discussing the kind of Zine *they* would like to see, in the hopes that such a thing would be of value to other C++ enthusiasts. This makes it, IMO, very different than CUJ. I can say no more about this here, but it will be different than CUJ indeed. There is room for both venues (some people strongly prefer print), but I think Boost folks will prefer what will appear over time in The C++ Source. If I (and the Board) didn't, we wouldn't waste our time. Having been instrumental in both publications, I know the difference. The fact that *for now* no one is getting paid should lend some credibility to the effort (but see below for more on that). In addition, anyone can contribute, not just "experts". This is an important distinction. (Besides, even Andrei Alexendrescu was an unknown until Scott Meyers "discovered" him. Latent experts need a venue to precede their notoriety). brlbo> If there's only room for one, I would prefer the one that is explicitly brlbo> peer reviewed, myself. I understand that programming in C++ is brlbo> an engineering pursuit, and not an academic/scientific one, but I brlbo> don't see that as a reason to hold it to a lesser standard. brlbo> Dave (Held) It won't be an academic journal, only peer reviewed. The articles will be written by and for C++ practitioners. The reviewing makes for better content, clearly. I see it sort of a publication equivalent of Boost - a place for peer-reviewed articles instead of software. FYI, the funds at CUJ dwindled so terribly (note the current minimized page count and disappearance of certain columns, letters, etc.) that I had to depend on the gracious kindness of my colleagues to review articles gratis. I don't know what the current arrangements are there (I have reason to believe that no one reviews articles there except the editor-in-chief, but that will have to be a private discussion), but the only people reviewing articles at CUJ besides myself for 2002-2003 were David Abrahams, Bjorn Karlsson, and Kevlin Henney. I managed to get a (very) few pennies for only one of them. When the holding company fired everyone but me and folded production into the DDJ machine, I left. That was October 2003. I tested the waters for a new Zine, a place with quality you can trust, by emailing those whose names appear on the Editorial Board of The C++ Source. The response was overwhelmingly positive - I can provide you moving quotes for the value of an online, peer-reviewed Zine from these experts we revere. The fact that things incubated until now shows our careful and good intentions. It is important to me that you (the Boost Community) understand this. brlbo> Actually I like the idea that people should get paid for their efforts, brlbo> while at the same time I do very much appreciate the efforts of those who brlbo> don't get paid such as the Boost developers in putting out free software. brlbo> My suggestion for a subscription to the C++ Zine was to help those who were brlbo> willing to put out the effort of writing articles, and developing software brlbo> based on them, to get paid. (Eddie) A valid point, with which I agree, but they *will* get paid, just not immediately. We have some advertising lined up and some other hopefuls. I think we'll get to the point where the remuneration will be worthwhile. We ourselves are professionals, and want to get paid, and don't want to slight anyone. The difference between The C++ Source and other venues is that we are not owned by a holding company needing to make Wall Street happy, and who from an uninformed distance may fire an entire long-standing family of fruitful employees to fill investors' pockets. [The people in Lawrence, Kansas, who made CUJ what it is over the last 20 years, were all given their walking papers - I mean, who needs *them*, after all?!] Hats off to the pioneers who have donated initial articles and other contributions to this new endeavor. Now that we've all had a chance to express opinions (thank you!), may I once again just invite you to read and contribute to The C++ Source, a peer-reviewed Zine created by and for people such as yourselves. Please send proposals, articles, and other offers of service to me at chuck(a)freshsources.com. Thank you! -- Best regards, Chuck Allison

1 0

[Boost-bugs] [ boost-Bugs-973310 ] jam_src build scripts need como --c
by SourceForge.net 15 Jun '04

15 Jun '04

Bugs item #973310, was opened at 2004-06-15 10:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=973310&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Evans (cppljevans) Assigned to: Nobody/Anonymous (nobody) Summary: jam_src build scripts need como --c Initial Comment: Without the como --c option, the command: build.sh como results in several .c files. For example: "execunix.c", line 225: error: identifier "vfork" is undefined if ((pid = vfork()) == 0) ^ Also, on debian, PATH_MAX is undefined in pwd.c. Output of como -c --list pwd.l pwd.c shows: N#include <limits.h> L 1 "/usr/lib/gcc-lib/i386-linux/2.95.4/include/limits.h" 1 N/* This administrivia gets added to the beginning of limits.h N if the system has its own version of limits.h. */ N N/* We use _GCC_LIMITS_H_ because we want this not to match N any macros that the system's limits.h uses for its own purposes. */ N#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */ N#define _GCC_LIMITS_H_ N N#ifndef _LIBC_LIMITS_H_ S/* Use "..." so that we find syslimits.h only in this same directory. */ S#include "syslimits.h" N#endif indicating that syslimits.h is skipped. Maybe that's part of the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=973310&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Re: Geometric Algebra Library
by Johannes Brunen 15 Jun '04

15 Jun '04

Hi, Jaap Suter wrote: >> Despite some >> positive replies, I got the impression that there were not a lot >> of people in the Boost community who saw any practical uses for >> such library. Ken Hagan wrote: > For a full geometric algebra, I suspect the target market is going > to be limited to a few thousand people worldwide, This may currently be correct. However, IMHO GA will gain a lot of importance. E.g. I'm working in the CAD industry and we are beginning to be aware of GA's strength against the classic mathematical toolset. I see a time comming that you learn GA in high school. Every physics student will be learning GA once it has found its way to the theoretical courses. Thereafter GA will gain room in the engineering fields. > most of whom have > never heard of boost and are unwilling to learn C++. I don't share this opinion. C++ has its place in the world, and a lot of applications which are a target to GA are programmed in C++. I think that people are willing to learn C++ if they see that the language and its tools (like boost) can help them to solve their problems (e.g. GA, CAD, robotics,...) better than other languages and tools. This was exactly the way I found myself at this place. > I wrote some GA classes for the 3D case about a decade ago, and I'm > still using them, but they are a very minor part of my work and I've > no reason to "upgrade" to a boost version, no matter how yummy it looks. > I'd like to be more positive, but I have to be honest. If you are pleased with your tools that is fine. But there are other people which could benefit a lot from a well shaped GA package. And more importantly, there will be new applications written which have to decide about the tools they use to solve there math. They probably won't write a new GA package and will stick with the classic tools. However, if available they may make the transition to a boost GA package. > However, you may be asking the wrong question. There are reasonable > arguments for using only one library for all your geometric algebra > and the demand for complex numbers is demonstrably large enough to > justify including it in the language standard. At first I wrote 'I second that!', but I have a problem with the part about complex numbers. GA is not a replacement for std::complex. > Given that GA is a superset of these, could your library replace > these two? It would need to be syntactically compatible, since we > can't break existing clients of std::complex, but since all such > libraries try to follow standard mathematical notation this might > not be too difficult. And IMHO GA should not try to supersede the classic tools since there still will be demand for them. I think they can perfectly coexists. People shoud choose the tools which best serve their needs. Finally, I strongly encourage Jaap Suter as well as Paul Leopardi (http://lists.boost.org/MailArchives/boost-users/msg06695.php , http://glucat.sourceforge.net/) to bring their libraries into the boost review process. With kind regards Johannes

3 2

Request for small test in CW 9.2
by Joaquín Mª López Muñoz 15 Jun '04

15 Jun '04

During the porting of my library, I found the following compiler bug in CW 8.3: **BEGIN PROGRAM** #include <iostream> struct foo { foo(){} foo(const foo&){} ~foo() { std::cout<<"~foo"<<std::endl; } }; template<typename T> struct A { static void bar() { const foo& f=foo(); std::cout<<"inside A::bar"<<std::endl; } }; struct B { static void bar() { const foo& f=foo(); std::cout<<"inside B::bar"<<std::endl; } }; int main() { std::cout<<"calling A::bar"<<std::endl; A<int>::bar(); std::cout<<"calling B::bar"<<std::endl; B::bar(); return 0; } **END PROGRAM** *Without* enabling the option "ISO C++ Template Parser", everything works dandy and the program output is: calling A::bar inside A::bar ~foo calling B::bar inside B::bar ~foo But if I enable the "ISO C++ Template Parser", the output becomes: calling A::bar ~foo inside A::bar calling B::bar inside B::bar ~foo Which is AFAICS a flagrant bug (note that ~foo() is called before A::bar() scope ends.) Fortunately, I know how to patch this in CW 8.3 with some pragmas. I'd be grateful if someone with access to CW 9.2 can check whether the error persists in this newer version of the compiler, so as to extend (or not) the patch to cover it as well. Remember, the problem only shows when the "ISO C++ Template Parser" is turned on. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[program_options] vc6 and vc7: explicit function template arguments
by Vladimir Prus 15 Jun '04

15 Jun '04

Hello, it appears that both vc6 and vc7 don't understand explicit function template arguments, like this: value<string>()->implicit() where 'value' is a function. Anybody can suggest a workaround? One possible approach would be to make 'value' a class which overloaded operator->, but that's a lot of work. TIA, Volodya

2 2