- Boost - lists.boost.org

[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

CVS problem
by Janusz Piwowarski 15 Jun '04

15 Jun '04

Hello, >From yesterday evening to now, there's agurtovoy's lock in /cvsroot/boost/boost/boost/python/converter. Regards, Janusz

2 2

RE: [boost] Re: Announcing a New C++ Zine
by Glen Knowles 15 Jun '04

15 Jun '04

>From: David Abrahams [mailto:dave@boost-consulting.com] >>>>>Has William reappeared? >>>> >> As last resort, his phone number is listed ;-) > >But I forgot what state he lives in. >From http://www.boost.org/people/william_kempf.htm Bill Kempf lives in Omaha, NE with his wife Bonnie, his cat Dexter and his two Chinchillas, Chimney and Minuet. He married on Oct. 30, 1999 where he and his wife held a Halloween costume reception. If that doesn't give you an idea of what kind of guy he is, nothing will. Glen

2 1

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

14 Jun '04

Jeff Flinn wrote: > Has William reappeared? Actually, I haven't heard from him for a while. This is not the final list. I will soon do a final query of those who want their names to remain on the Editorial Board (and of course, others can be added). The list I sent contains those who have participated in the forming of The C++ Source since last October. You might want to ping him with a private message. I should add here that I forgot to mention in my original post that for now, contributing to The C++ Source is a "labor of love". None of us are getting paid. As we get sufficient advertising, we will share the wealth. We are starting small, but I predict a gradual swelling until this becomes a mainstay for the majority of C++ developers. Someone has suggested a subscription basis, but with today's Internet culture, I think we'll do the most good if we keep it free. That can change, but for now, that's the way it is. After all, Boosters are very familiar with this model :-). -- Chuck Allison

7 12

Announcing a New Online C++ Zine
by Chuck Allison 14 Jun '04

14 Jun '04

Hello Boosters, David Abrahams suggested I could send you an announcement on this list. For some time now (since last October, actually) a group of C++ luminaries have been discussing the virtues and possibilities of a peer-reviewed source for the C++ community. We have decided on the name "The C++ Source", and a preliminary page is available for viewing at http://www.artima.com/cppsource. The idea is to have seasoned C++ professionals review submissions to ensure that the publications are of high quality and of interest. There will also be tutorials, news, lots of stuff. The Editorial Board currently is: David Abrahams J. Stephen Adamczyk Andrei Alexandrescu Matthew Austern Pete Becker Walter Bright Steve Clamage Greg Colvin Jim Coplien Stephen Dewhurst Howard Hinnant Bjorn Karlsson William Kempf Andrew Koenig Martha Masinton Scott Meyers Thomas Plum Dan Saks Jerry Schwarz Jeremy Siek Bjarne Stroustrup Herb Sutter Matthew Wilson Leor Zolman (Like, wow!) I am writing to invite you to consider writing for The C++ Source. In fact, the first installments to appear later this month include an article by Booster Bjorn Karlsson. The chances that anything of interest to you will be of interest to the C++ community at large, and will make a positive contribution to daily C++ development. If you have any ideas, proposals, or suggestions, please email me at chuck(a)freshsources.com. Thanks! -- Best regards, -- Chuck Allison

5 5

RE: [boost] Re: Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

John Nagle wrote: >Robert Ramey wrote: >>As far as writing documentation is concerned I found the the "standard" >>boost position at: >> >>C:\boost_1_31_0\more\writingdoc\index.html > > I'm having trouble reading your C: drive. Try replacing "C:\boost_1_31_0" with either http://www.boost-consulting.com/boost or the directory where your copy of Boost is located, e.g.: http://www.boost-consulting.com/boost/more/writingdoc/index.html HTH Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

David B. Held wrote: >Ok, if the Boost style documentation is too simple, and docs like >Spirit are too cute, what is a nice, happy median? Have you looked at the BoostBook generated docs :). Let me know what you think of the current L&F: I have updated this a while ago to try and bridge the gap between the two looks (the docs now have Spirit-style navigation). See http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/doc/html/ind… for the new-stle docs. >If we're going >to demand uniformity in licensing, should we also demand more >uniformity in documentation? I agree on this. At the moment, we have the docs written in HTML, those in BoostBook format (like Boost.Any and the BBv2 docs) and the Spirit docs which have their own format. As far as I understand it, the BoostBook tool is relatively new and has a learning curve, so it will take some time to migrate the docs to this format. As for the Spirit docs, they have their own sourceforge area as well as being a part of Boost, so forcing them to change doc format wouldn't be fair. However, since the Spirit docs are in a special text format that is "compiled" into HTML using Spirit, it should be easy to create a BoostBook back-end and have the docs in boost in this format and the ones on the sourceforge area in the existing format. With this in mind, it might be beneficial to create a HTML to BoostBook converter (possibly using Spirit) to allow easier migration to the BoostBook format. >I think a single documentation style >across Boost would make it even easier to learn new libraries. I >recently found it very difficult to find the information I wanted about >the Boost.Test library, as well as Boost.Preprocessor. What can >be done about these issues? I think the BoostBook format would go a long way to resolving these issues, once the docs are all in this uniform format. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

6 6