- Boost - lists.boost.org

Re: [boost] Re: [Boost-announce] Formal Review Tribool
by Haim Cohen 01 Jun '04

01 Jun '04

Sorry if this is a repost - I am almost sure my last post did not reached out. Rob Stewart wrote: > meaning "arbitrary value." However, "indeterminate" leaves no > doubt as to the meaning of the value and doesn't depend upon > one's experience with electronics. Another possibility would be I agree. Although I see the highest potential of the library in EDA applications, the meaning of the value should not depend on any problem domain - like electronics. I guess I was little bit biased here by my problem domain. > As I've already rejected the "x" notion, that leaves > "unknown_bool" or, by extension, "indeterminate_bool." While > these names suggest that there is an unknown or indeterminate > Boolean value, they don't suggest to me a type that includes > true, false, *and* unknown/indeterminate. "tribool," OTOH, I disagree. IMHO, The name unknown_bool hints that in addition to the 2 traditional values of bool, there is also an unknown bool. I am not a native user of the English language, but this is what the name unknown_bool hints *me*. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen(a)analog.com / haimcohen2002(a)hotmail.com Analog Devices

1 0

[Formal review request] policy_ptr
by David B. Held 01 Jun '04

01 Jun '04

I am formally requesting that policy_ptr be added to the review queue. The version to be reviewed is different from the version currently in the sandbox, but will be available long before the current queue is exhausted. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004

3 3

Boost Software License & GPL
by Alex Vinokur 01 Jun '04

01 Jun '04

<QUOTE from http://www.boost.org/more/lib_guide.htm#License> License requirements The preferred way to meet the license requirements is to use the Boost Software License. See license information. If for any reason you do not intend to use the Boost Software License, please discuss the issues on the Boost developers mailing list first. </QUOTE> I am thinking of submission some software to Boost. However I put this software in several sites under GPL. Boost requires Boost Software License. How to solve this problem? -- Alex Vinokur mailto:alexvn@connect.to http://mathforum.org/library/view/10978.html

3 3

bjam - adding includes
by John Torjo 31 May '04

31 May '04

Hi all, Is there a way to add an <include> to bjam, by specifying it on command line? In particular, I'm trying to build a non-boost library, which needs boost ;) Therefore, I need to specify the path where boost headers are. Since I want to distribute this library, I don't think that adding an <include> in the jamfile, specifying where my boost is installed is the way to go ;) So, is it possible? If so, how? Thanks. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 2

[multi_index] Volunteer to help porting to VC7.0?
by Joaquín Mª López Muñoz 31 May '04

31 May '04

Regression tests for VC7.0 show a recurrent problem throughout the library with a specific facility in boost/multi_index/detail/allocator.hpp. My hunch is that this should be easy to fix, but it is not productive to try variations on the main CVS and wait for the regression tests outputs. Anyone with VC7.0 volunteering to help with porting of Boost.MultiIndex to VC7.0? If so please contact me and I'll provide you with all the relevant info and some suggestions of things to try. I think this souldn't be to hard to fix. Thanx in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Volunteer for a little test in MSVC 7.0?
by JOAQUIN LOPEZ MU?Z 31 May '04

31 May '04

I'm trying to make Boost.MultiIndex work for MSVC 7.0 an the regression tests show some weird results. I'm suspicious this can be related with a similar problem in MSVC 6.0 having to do with pointers to members being used as template prams. Would any kind soul with access to MSVC 7.0 run the following test and report the result? TIA Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ****************** struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)return -1; return 0; } *****************

5 5

Metrowerks: member template specialization problem
by Vladimir Prus 31 May '04

31 May '04

I get the following error from metrowerks: http://tinyurl.com/2z6st It seems that given: template<> bool basic_config_file_iterator<wchar_t>::getline(std::string& s); template<class charT> bool basic_config_file_iterator<charT>::getline(std::string& s) { return std::getline(*is, s); } Metrowerks decides to use the second, unspecialized version, even for basic_config_file_iterator<wchar_t>, and this surely fails to compile. Anybody knows what could be the reason? The entire header which causes the error can be found at: http://tinyurl.com/2rapj Thanks in advance, Volodya

3 6

[Formal review result] Collection Traits Library
by Hartmut Kaiser 30 May '04

30 May '04

Hi all, after working through the pile of mails submitted for the review of the Collection Traits Library from Thorsten Ottosen, it is obvious, that it is ACCEPTED to Boost. All of the reviewes voted YES to include the library. Congratulations Thorsten! Most of the issues brought up during the review (mainly documentation nitpicks) were resolved already by Thorsten (or Thorsten agreed to fix them). Here are the open ones: 1) There were some discussions, whether the library should be renamed and/or incorporated with other ongoing efforts. There was no definitive consensus, how to achieve this. But the discussions showed that it seems to be good, if the collection traits library could be integrated with other libraries, existing and currently developed, to make it a part of a future Boost.Range library. I'm sure, that we'll see a lot of corresponding discussions in the future. 2) The strong requirement that end() should have constant complexity rules out the integration of C-strings into the library. Additionally special threatment of char[] arrays is needed, so they behave in the same way as their char* conterparts. The problem, that end(char[]) pointed to the byte after the '\0' was corrected already. Regards Hartmut Review Manager

2 1

dynamic_bitset tests and help request to Metrowerks users
by Gennaro Prota 30 May '04

30 May '04

Hi everybody, as promised the dynamic_bitset tests are being _slowly_ settled. My apologies for the very "calm" pace but that's all that my spare time allows me. This morning I've fixed an error caused by VC6's Dinkum Lib. Since the library in this case affects the dynamic_bitset behavior I'd like to ask for you opinion. Try the following program, which attempts to read a string from an *empty* file: #include <iostream> #include <ostream> #include <fstream> #include <string> int main() { using namespace std; ofstream of("a_temporary_file"); of.close(); ifstream f("a_temporary_file"); string s = "help"; f >> s; std::cout << "The string is now " << s << '\n'; std::cout << "(length = " << s.length() << ")\n"; } With VC6's library the string is erase()d. That's because the code in the sentry constructor fails to set an error bit in the stream state if the file is empty. With all other libraries at least eofbit is set (according to lib issue 195 failbit should be set too but many implementations deliberately avoid that; see for instance: http://gcc.gnu.org/ml/libstdc++/2000-q1/msg00086.html) thus bool(sentry_object) is false and the string remains untouched. With dynamic_bitset the situation is exactly the same, as the extractor relies on the underlying library to construct a sentry. Now, the question is: do you see any problems in this? Note that it means attempting to extract a dynamic_bitset from an empty file clears the bitset with VC6's Dinkum while leaves it unchanged on (all) other implementations; however the behavior is consistent with extractions of other types (std::strings) on each platform. Fixing the behavior at the dynamic_bitset extractor level to make it consistent across different standard libraries would be, I think, quite tricky (and ugly). Secondly, a help request. There are some MW errors which I won't be able to fix, as I don't have access to that compiler: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/output/bin-b… If anyone wants to submit a patch I'd be more than happy to integrate it. Thanks, Genny.

3 6

RE: [boost] Re: changing aCC-Link-action
by DY, JERRY U (SBCSI) 30 May '04

30 May '04

I have attached the updated acc-tools.jam file located in boost_1_31_0/tools/build/v1. I added the following option to the compile line: +z - to make the compiler generate PIC (position independent code) -- required for shared libraries. -w - suppresses warning messages And to the link line: -b - to tell the linker to generate a shared library instead of an executable. I'm assuming that aCC-Link-action is only used for generating shared library? Do you happen to know which thread functions where missing? -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Tuesday, May 11, 2004 1:50 PM To: boost(a)lists.boost.org Subject: [boost] Re: changing aCC-Link-action "DY, JERRY U (SBCSI)" <jd2419(a)sbc.com> writes: > I would like to add options to the compile and link line used for > building the threads library. I have added as follows but not sure if > it's the proper place for it. With these changes, I'm able to cleanly > compile and build the threads shared lib using aC++ 3.55 compiler. > Credit to the HP aC++ team for their help on hpux.hpp changes. > > boost_1_31_0/tools/build/v1/acc-tools.jam:105 > $(acc.bin-directory)$(CXX) -AA -mt +z -w -c +W823 -I$(BOOST_ROOT) > -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDR > S)" -I"$(STDHDRS)" -o "$(<)" "$(>)" > > boost_1_31_0/tools/build/v1/acc-tools.jam:82 > $(acc.bin-directory)$(CXX) $(LINKFLAGS) -AA -mt -b -o "$(<[1])" > -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" > -l$(FINDLIBS) > > boost_1_31_0/boost/config/platform/hpux.hpp:63 > #define BOOST_HAS_PTHREADS Hi Jerry, Thanks for the info. I don't think we want to define BOOST_HAS_PTHREADS unconditionally, because IIRC at least some versions of HPUX's headers don't contain one or two of the functions used by Boost.Threads It's more effective to post a patch as an attachment, so there's no ambiguity about how mailers have mangled it, and so it can be automatically applied. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 7