- Boost - lists.boost.org

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

iostreams library review
by slavek.f.kuzniar＠jpmorgan.com 29 May '04

29 May '04

On Boost mailing archives I found a review request for Iostreams Library by Jonathan Turkanis. I did not see any follow-up and the library is not part of latest release so I suspect the review did not happen. Anyone knows what is the fate of this library? This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.

4 4

RE: [boost] Re: [prereview request][fsm]
by Brian Braatz 29 May '04

29 May '04

My 2 cents """""""""""""""""" This is certainly doable. However, I'm unsure whether the current > design allows a you-don't-pay-for-what-you-don't-use implementation of > such a feature. Plus, I'm still not convinced that this feature would > be used more than rarely. Do you have some real-world use cases in mind? [David Abrahams] Unfortunately I'm not so familiar with what exit actions in FSMs are typically used for, but from an abstract point of view I don't think of resource releasing as an "action". If you were writing this stuff in a GC'd language, for the most part, you wouldn't devote any exit action code to resource releases. """""""""""""""""' I think this is a very good point as MS seems (IMO\whether I like it or not) to be driving us down a managed GC path for future C++ efforts. This is something to deeply consider. Not that MS is "everything", but they do have a lot of C++ developers using their tools and os's.

3 4

Re: [prereview request][fsm]
by Darryl Green 29 May '04

29 May '04

Andreas, I have looked more thoroughly at the fsm library and have this specific problem I would like advice on. The source state (as well as all the rest of the active direct and indirect inner states of the innermost common outer state) is destructed before the transition action runs. This means the actin doesn't have access to any of this context, considerably reducing the utility of state local storage. The stopwatch example shows the storage being used in the exit action, which is fine. A more complex example would be likely to have separate actions for multiple transitions. It seems that if actions need access to the state local storage of a state being left one must do the following: 1) Have states with only one transtion. 2) Be prepared to execute the actual "work" done by the system (the actions) in the exit action (which is a destructor). I don't find either of these attractive. Alternatively, a custom reaction can be used. The react function can do processing in the context of the source state (it is a member of the source state). I'm not sure how easy it is to access other active (inner or outer) states at this point? So I end up with a "pre exit" action. User defined exception handling can be used here (that is, it is possible to: 1) map an exception to an event 2) make (or not) an immediate transtion to an arbitrary state based on an exception 3) terminate 4) let the fsm framework deal with it This seems reasnably ok, but doesn't make for a nice transition table representation (the transition information is "hidden" in the react() function). Another option is: Keep a shared_ptr<my_local_storage> in the state. Construct a my_local_storage in the state constructor. In the react member function, take a copy of teh shared_ptr. This should keep my storage "alive" until the transition is complete and the new state has been entered (actually a bit longer than I would like). Am I missing something or doing something wrong? Can you recommend an approach to deal with this? Thanks Darryl Green.

2 1

Re: [boost] port of test library to vacpp
by JOAQUIN LOPEZ MU?Z 29 May '04

29 May '04

Hi Daryle ----- Mensaje original ----- De: Daryle Walker <darylew(a)hotmail.com> Fecha: Sábado, Mayo 29, 2004 6:36 pm Asunto: Re: [boost] port of test library to vacpp > On 5/27/04 5:14 AM, "Joaquín Mª López Muñoz" <joaquin(a)tid.es> wrote: > > [SNIP] > > Maybe the following is a good compromise > > > > #if defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) > > enum npos_type { npos = (size_type)-1 } > > #else > > static const size_t npos = (size_type)-1; > > #end > > Doesn't the BOOST_STATIC_CONSTANT macro cover this? > Not quite. BOOST_STATIC_CONSTANT generates an *unnamed* enum, which is pecisely what was causing the error that originated this thread. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Quick question on XCode
by Daryle Walker 29 May '04

29 May '04

In case you're wondering where I've been, I was formatting my computer and installing Mac OS X 10.3 Panther on it. It comes with the "Project Builder" replacement, "XCode". Unfortunately, it completely changed its project configuration philosophy. Does anyone know how to add (project specific) search directories? I would need configurations that would use Boost-CVS, the latest Boost archive, the Sandbox CVS + Boost CVS, or the Sandbox CVS + Boost archive. (The sandbox would need to be searched first.) I haven't reinstalled by copy of Metrowerks CodeWarrior Pro 8.3 yet. I should get a new copy of more-I/O uploaded to Yahoo soon. (I noticed that the latest library under review jumped more-I/O's spot in the queue. [There were no definite schedule after the review before this one.] I let my e-mailbox overflow and missed all the mail on May 22nd. Did the rescheduling happen then?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

port of test library to vacpp
by Toon Knapen 29 May '04

29 May '04

( Currently the regression status pages for IBM and SGI are not updated for two weeks because I'm unable to even compile the regression test tools. And more and more libraries are braking (on vacpp) so here's another shot at getting them to run again. ) In boost/test/detail/basic_cstring/basic_cstring.hpp contains following line: "enum npos_type { npos = (size_type)-1 }" Now size_type is previously defined as a size_t. The IBM is a 64 bit machine and size_t is 64 bits wide whereas an int is 32 bits wide. Therefore VisualAge does not accept this line. Would soth break if we change this to "enum npos_type { npose = -1 }"

8 13