- Boost - lists.preview.boost.org

[serialization] autolinking
by JOAQUIN LOPEZ MU?Z 23 May '05

23 May '05

I'd like to know which the circumstances are under which Boost.Serialization autolinking feature kicks in. Last time I discuseed with Robert about this (see http://lists.boost.org/MailArchives/boost/msg78596.php) seemed that autolinking won't affect programs that are only including boost/serialization/* headers but *not* including any of *_?archive.hpp. But recent tests in the mslater regression runner (for instance http://tinyurl.com/a3n6u) suggest that this may not longer be true. Clarification, please? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

RE: Logging library - your own scenario! (John Torjo)
by Shanks, Graham 23 May '05

23 May '05

Most of our scenario has been covered by other posts, i.e. configurable levels of logging, configurable destinations - including an in-memory cyclic buffer (sometimes the only way to catch fatal bugs on a system without an ICE or core dump), etc. One thing that I would really like to have that hasn't been mentioned before is the ability to configure how char types (including signed and unsigned) are logged. A lot of our work is low level network related and logging messages is important. For this we almost always use char types to contain numbers, but of course any use of stream inserters will treat them as characters, something that can ruin a complete log (if serialised as text). Although it could be said to be our responsibility to ensure that any data logged via a stream inserter is formatted correctly sometimes it is easy to forget. The ability to configure the logging library to specify how types are formatted in the log would be extremely useful (and probably not just for this scenario). The cppunit library allows the format of types output to be configured by introducing a specialisation of a traits class which would be useful. It could look something like: template<> struct log_traits<unsigned char> { static std::string toString( const unsigned char& x ) { std::ostringstream ost; ost << static_cast<unsigned int>(x); return ost.str(); } }; I have not yet had time to look at your library so if this feature is already included then please accept my apologies - but count it as a vote for its retention :-) Graham Shanks ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************

1 0

Logging library - your own scenario!
by John Torjo 23 May '05

23 May '05

Hi all, In order to make the Logging lib as usable as it can be, I'd like to know what is *your* scenario, when using a Logging lib. Thus, I'll do my best to make it as easy as possible to use my lib, and also tweak it to be easily usable in most common scenarios. Even if you scenario fits an already described one, please just reply to that email with something like "mine too!", so that I'll know which scenarios are most common. Thanks! Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

15 37

[serialization][test] Helping end-user testing serialisation
by Loïc Joly 23 May '05

23 May '05

Hello everybody, I think I have some idea that might improve the ease for the end user to test if he properly set-up his class for serialization. Sorry if this idea has already been discussed (or even is already implemented), but I tried to search a little, without finding anything about this. The main idea is that if an user has a serializable class, he will probably want to test wether he forgot to put some usefull member data in his |serialize function. Thus, he will have to write some test with always the same pattern. My suggestion is to put test_tools.hpp inside the serialization library, along with some template :| || |template<class T> void check_serialization(T const &t) // t should not be initialized to default values| |{| | const char * testfile = boost::archive::tmpnam(NULL);| | BOOST_REQUIRE(NULL != testfile);| | {| || std::ofstream ofs(testFile); | boost::archive::text_oarchive oa(ofs);| | oa|| << t;| | }| | { ||| T t1; || std::ifstream ifs(testFile, std::ios::binary); | boost::archive::text_iarchive ia(ifs); | ia >> t1 ||| }| | BOOST_CHECK_EQUAL(t, t1);| | std::remove(testfile);| |||}| |||| Do you think it would make a worthy addition ? -- Loïc | |

3 2

[Boost-bugs] [ boost-Bugs-1206663 ] call to split_winmain raises exception for 8-bit locale
by SourceForge.net 22 May '05

22 May '05

Bugs item #1206663, was opened at 2005-05-22 13:05 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=1206663&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: call to split_winmain raises exception for 8-bit locale Initial Comment: This bug is detected for boost::program_options::split_winmain function and debug version CRT of the VC 7.0 under WinXP. The problem is: split_winmain (winmain.cpp, line 62) uses isspace() from VC CRT. The isspace() got int value which < 0 and not EOF and raises exception. That int value is russian symbol in rus_russia.1251 locale and casted to int. Before to call to winmain i had setted locales for CRT and STL: if (NULL == setlocale(LC_ALL, "rus_russia.1251")) { ... } std::locale::global(std::locale("rus_russia.1251")); ... I suppose, there is simple fix: change isspace(*i) call to isspace((unsigned char)*i) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1206663&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[build] relative vs absolute
by Yuval Ronen 22 May '05

22 May '05

Hi all. I have a question which is somewhat Boost-related and somewhat general. I've looked at the build system (i.e, Jam files) and noticed that most of time, the directories (include directories, link directories) are specified in absolute format - $(BOOST_ROOT)/whatever. However, not all of them are absolute. Some are relative - ../../../whatever. Other parts of the Boost tree, such as the html files, contain relative paths. My question is: shouldn't there be a uniform way - absolute or relative? And if so, what would it be? My opinion is that relative is superior, because is makes it possible to checkout several instances of the tree (several branches, or even several instances of head) to separate parts of the disk and work on all of them as needed, without mangling with environment variables. What I mean is that requiring to change environment variables is burdensome and errorprone (I can easily execute bjam from directory X, while BOOST_ROOT points to directory Y, which will create a disaster). What is your opinion regarding this in repect to Boost, and in respect to other projects in general? Many thanks for your time, Yuval

3 9

regex documentation redirected
by Stephen Lamb 22 May '05

22 May '05

Not sure if this is intentional but http://www.boost.org/libs/regex/index.html is redirecting to http://www.boost.org/libs/regex/doc/index.html. It would be nice for users to eliminate the redirection and go directly to the correct page. Thanks, Steve

2 1

Re: [boost] [serialization] autolinking
by JOAQUIN LOPEZ MU?Z 22 May '05

22 May '05

----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Domingo, Mayo 22, 2005 1:56 pm Asunto: [boost] [serialization] autolinking > I'd like to know which the circumstances are > under which Boost.Serialization autolinking feature > kicks in. > > Last time I discuseed with Robert about this > (see http://lists.boost.org/MailArchives/boost/msg78596.php) > seemed that autolinking won't affect programs > that are only including boost/serialization/* headers > but *not* including any of *_?archive.hpp. > But recent tests in the mslater regression runner > (for instance http://tinyurl.com/a3n6u) suggest > that this may not longer be true. Clarification, > please? Thank you, > For the record, multi_index metacomm tests have just begin failing in msvc-stlport and vc7, for the very same reason, see for instance http://tinyurl.com/7ewf4 http://tinyurl.com/cpyoa Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Building from current CVS
by Marcin Tustin 22 May '05

22 May '05

I'm trying to build from the current CVS (actually about a week old), and it has some weird problem with creating files and directories. When trying to build with a version of Jam from 1.32, it always falls over trying to create a file or directory, normally mentioning Mkdir1 first. When trying to build the version of Jam that comes with the CVs source, it is able to build jam0.exe, but when it comes time to make bin.ntx86 it fails; and if that directory exists, the jam executable is not created; instead an error about "spawn: No such file or directory" is emittted. I am using vc 7.1. Any ideas for a better way to build the boost libraries?

2 1

Logging Library -- Formal Review Request
by John Torjo 22 May '05

22 May '05

Hi all, I've just updated the Boost Log Library: http://torjo.com/code/logging-v132.zip I would also like to ask for a _Formal Review_. The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

13 54

RE: [boost] Logging library - your own scenario!
by Spencer.Collyer＠barclayscapital.com 22 May '05

22 May '05

Hello John The situation we have here for logging is as follows: a) All logging goes via a Logger singleton. b) The output destination of the Logger is configurable at runtime. We currently have LogOutputters for file, console, and network. These LogOutputters are roughly equivalent to your appenders. c) All log messages belong to a particular topic. Topics are arranged hierarchically, which is important when considering log levels. d) All log messages also have a particular log level. These range from 'CRITICAL' all the way down to 'DEBUG4' (yes, we have four different levels of debug messages). Log levels and log topics are orthogonal to each other. e) A particular log topic can have a minimum log level specified, and any messages on that topic with levels below that level will not be logged. If a log topic does not have a level explicitly set, it inherits its level from its parent in the hierarchy, working its way up the tree until it finds a topic that has a level set. Hence, topic '/sm/message/builder' will inherit from '/sm/message', and if that has no level set then they both inherit from '/sm'. The root topic always has a level specified, even if it is the default of 'INFO'. Note that in our scheme it is impossible to turn off CRITICAL messages. f) We have a defined 'syslog' log level. All messages of that level and above are sent to the syslog, even if they are turned off for their topic. g) Log messages are sent to the LogOutputters in a structured format, with date/time, pid/tid, topic, level, and message all seperate. The LogOutputters determine how these values are formatted. h) We have the ability to adjust log levels by topic while a program is running. i) As a corollary to (h), and in contrast to what a lot of people have said, we do *not* turn off logging in our production code. However, note that all our programs are strictly 'in-house' so this is probably an unusual requirement. j) We do not do any kind of log rotation within the logging system itself. However, we do have external programs that rotate logs for us on a daily basis, and our file LogOutputter has the ability to insert a timestamp into a logfile name or append rather than overwrite on startup. Spencer ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------

3 2

Re: [boost] Logging library - your own scenario!
by John Torjo 22 May '05

22 May '05

Dan, thanks for your thorough feedback! >> > > Here's what OpenWBEM does. > > > ------------------------------------------------------------------------ > > ----------------------------------------------------------------------------- > Definitions: > log > n. The end-point that log messages are sent to. Examples include a log file, syslog and the console. > v. The act of generating and outputting a message. e.g. The error message was logged. > Yup > logger > A C++ instance of a class derived from Logger, which is used by the OW code to output log messages. > Not sure why needed, I have appenders and modifiers. > component > A string identifying the logical grouping of code within OW that generated a log message. It is useful to organize components hierarchially, using a "." to separate ancestor and descendent. The hierarchy is meaningless to OW from a configuration or API point of view, but it is helpful for log processing. > The component "*" is reserved for configuration to mean all possible components. > Examples include "owcimomd", "owcimomd.http_server", "owcimomd.http_server.local_auth", "vintela.computer_system_provider". > I assume this is equivalent to "log names", in my lib. > category > Associated with a message to indicate attributes of the log message. > Also commonly refered to as log levels. > The category "*" is reserved for configuration to mean all possible categories. > Examples include Debug, Info, Warn, Error, FatalError, Trace, AuthenticationFailure, etc. > The 4 categories "Debug", "Info", "Error", "FatalError" are treated as levels for configuration purposes. If a log is configured for Debug, all 4 categories will be output. > Otherwise there is no relationship between categories. > Yes, I need to implement this ;) > message > The text of a message. A message has the following attributes: component, category, source filename, source line number, date/time, process id, thread id. > By default, I use a simpler approach (that is, the text is a string), but you can specify a custom log manager, and configure it to keep most if not all of the above. > message format > A pattern which indicates the format of the log message and associated attributes. In my case, "modifier" functions. > > ----------------------------------------------------------------------------- > Feature requirements & Use case list: > > - Ability to log all messages at or below a threshold (one of the 4 predefined categories) into a log. > Yup, need to implmement this. > - Ability to configure a log for each component. e.g. A specific provider's messages all go to a log. The log only contains the provider's messages. > Already exists. > - Set different thresholds for different components of the cimom. e.g. If I'm interested in debugging one specific component, I can turn on debug logging for that specific component (say my provider I'm working on) and not have to wade through tons of other unwanted debug messsages. Need to implement it. > > - Ability to configure a log for a specific category. e.g. The error messages from all components go to a log. Not sure I understand here. Could you give me an example? > > - Ability to configure a log with a "component"/"message category" combination. e.g. auditing of authentication: it would be nice to be able configure logging of all authentication failures and/or successes, and nothing else, to a certain log. > So far, you can configure per "component". For each "component", you'll be able to set a "message category" for which messages are logged. Messages below and with this category are logged, while messages above this category are ignored. Setting the "message category" to DISABLED will ignore all messages that are sent to this log. > - User-defined logfile formats. Use the same formatting rules as log4j > (or log4perl, like specified at > http://search.cpan.org/~mschilli/Log-Log4perl-0.48/lib/Log/Log4perl/Layout/…) > Available data includes: [date and time] [pid/thread-id] [category] [component] [log message] > You can do this with modifiers. In the future, I plan to create a small library on top of logging lib, which will make it very easy to define logfile formats, and configure logging. (I say in the future, because I don't think I'll have the time to finish it in time for the review) > - Ability to output to a log that can be processed by log4j compatible log > processing tools (e.g. Chainsaw) > Hmmm... Need to dig into this... > - Ability to configure the console logging when the cimom is run in debug mode > (with -d) What's cimom? I've looked on the web, is it "Common Information Model Object Manager (CIM OM)."? (did not have time to do some heavy searching though) > > ----------------------------------------------------------------------------- > On to the design: > > Each log message will have an associated component, category, source filename, source line number, date/time, process id, thread id. > > { "Debug", "Info", "Error", "FatalError" } are the set of predefined message categories. This set may be treated as levels, so that a message with a higher level category is also considered matching a lower level category (i.e. a FatalError is also categorized as a Debug level). Additional categories may be used, but they are independent of any other category. They are also the most commonly used, so the API will have convenience functions for them. > > A log is configured with a name, components, categories, format, type and any specific logger information such as a filename. If a component == "*", then it will match all components. If a category == "*", then it will match all message categories. > Yup, will do. > For owcimomd, there is a predefined log named "main". The owcimomd.log_level and owcimomd.log_location config items will be deprecated but still supported, and they will affect this log if set. > > For owcimomd, there is a predefined log named "debug". This log will be > enabled when owcimomd is run with a -d. The default will be all categories > and levels. > > When a message is sent to a logger, it will be evaluated against each log's configuration and if it matches, the message will be formatted according to the format configuration and output to the log. > Need to dig deeper, to see what you mean. > ----------------------------------------------------------------------------- > Configuration > [...] As said, I'd like to create a small lib on top of logging lib, to allow such easy configuration. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

1 0

[wierd codewarrior 9.5 error]
by Thorsten Ottosen 22 May '05

22 May '05

Hi, Does anyone know the cause of http://tinyurl.com/dbn2n ? Thanks -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 2

[1.33.0] Regression test status
by Douglas Gregor 22 May '05

22 May '05

The following summarizes the regression test status of each of the Boost libraries. We're doing well, but there are still quite a few libraries with outstanding failures. I've listed those libraries here along with the compilers/platforms on which they are failing. May is half-way finished: I hope to stabilize by the end of the month for release. Lots of failures: iostreams (vc-7_1, vc-8_0, mingw-3_4_2, borland-5_6_4, gcc-3_3-darwin, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux, gcc-3.3.5-linux, gcc-3.4.3-linux, intel-8.1-linux). numeric/ublas (all compilers fail test4, test5) parameter (vc-7_1, borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux) program_options (borland-5_6_4, vc7, gcc-3_3-darwin, intel-8.1-linux) ptr_container (borland-5_6_4, cw-8_3, msvc-stlport, vc7, msvc, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux, vcc-3.4.3-linux) range (vc-7_1, vc-8_0, borland-5_6_4, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux, gcc-3.3.5-linux, gcc-3.4.3-linux) serialization (most compilers fail something) test (every compiler fails something) A few failures: algorithm/string (vc7, cw-8.3) date_time graph (vc-8_0) integer (msvc) iterator (borland-5_6_4) math (cw-9_4) multi_index (msvc) pool (borland-5_6_4) python (vc-8_0, msvc-stlport, vc7, gcc-3_3-darwin) random (gcc-3_3-darwin, gcc-2.95.3-linux, gcc-2.95.3-stlport-4.5.3-linux) regex (borland-5_6_4, msvc-stlport, vc7, msvc, gcc-2.95.3, gcc-2.95.3-stlport-4.5.3-linux) spirit (cw-8_3, gcc-3_3-darwin on multiprocessor machines) thread (cw-9_4, msvc-stlport, msvc) utility (call_traits_test on msvc-stlport, vc7, msvc) wave (cw-8_3) Libraries that with no failures: algorithm/minmax any array assign bind concept_check config conversion crc disjoint_sets filesystem format function functional functional/hash io lambda logic math mpl multiarray numeric/conversion numeric/interval optional preprocessor rational signals smart_ptr static_assert timer tokenizer tuple type_traits variant Doug

6 17

[Test] Warning Suppression?
by David Abrahams 21 May '05

21 May '05

Hi, I keep seeing c:\boost\boost/test/impl/execution_monitor.ipp(214) : warning C4535: calling _set_se_translator() requires /EHa Is the warning correct? If so I think we need to add the appropriate stuff to the build system to generate /EHa in this case. If not I think we need to add the appropriate warning suppression. -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 4

[Boost-bugs] [ boost-Support Requests-1205155 ] Building errors on windows with vc71stlport
by SourceForge.net 20 May '05

20 May '05

Support Requests item #1205155, was opened at 2005-05-19 10:28 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=1205155&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Building errors on windows with vc71stlport Initial Comment: Hi, I'm trying to install Boost on windows xp with stlport and Visual Studio .Net 2003. When building it with "bjam "-sTOOLS=vc-7_1-stlport" install" I'm obtaining errors that seems like: c-C++ bin\boost\libs\date_time\build\boost_date_time.dll\vc-7_1-stlport\debug\threading-multi\greg_month.obj greg_month.cpp C:\Documents and Settings\BOUJAC00\Bureau\boost_1_32_0\boost\lexical_cast.hpp(150) : error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'boost::date_time::date_names_put<Config,charT,OutputIterator>::string_type' (or there is no acceptable conversion) with [ Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=std::ostreambuf_iterator<wchar_t,std::char_traits<wchar_t>> ] The log of the build is include in log2.txt. Somebody have an idea of what I'm doing wrong? Thanks in advance JA jacques-andre.boulay(a)polymtl.ca ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1205155&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

iterator_adaptor: underlying iterator type?
by Aleksey Gurtovoy 20 May '05

20 May '05

Currently 'iterator_adaptor' exposes its underlying iterator _object_ (through 'base()'), but not its type, which stands in the way of a generic code manipilating adapted iterators/sequences, e.g.: template< typename Sequence > mtn::iterator_range< typename Sequence::iterator::base_type > // ^^^^^^^^^^^ // currently unavailable base_view( Sequence& seq ) { return mtn::make_iterator_range( seq.begin().base() , seq.end().base() ); } Any objections if I add the typedef (and update the docs correspondingly)? -- Aleksey Gurtovoy MetaCommunications Engineering

3 7

Re: [boost] Building from current CVS
by Victor A. Wagner Jr. 20 May '05

20 May '05

At 08:56 2005-05-20, you wrote: > I'm trying to build from the current CVS (actually about a week >old), and it has some weird problem with creating files and directories. > > >When trying to build with a version of Jam from 1.32, it always falls >over trying to create a file or directory, normally mentioning Mkdir1 >first. > >When trying to build the version of Jam that comes with the CVs source, >it is able to build jam0.exe, but when it comes time to make bin.ntx86 >it fails; and if that directory exists, the jam executable is not >created; instead an error about "spawn: No such file or directory" is >emittted. > >I am using vc 7.1. if I remember correctly, the spawn:.... happens when, for some reason, the vcvars32.bat didn't get get called so the environment doesn't get set up properly. btw, exact error messges are useful for us to help track down problems, and in many cases a few lines _before_ the error will help put things in context. >Any ideas for a better way to build the boost libraries? > > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Tuples: how to get rid off the open/closing characters??
by Oliver Kullmann 20 May '05

20 May '05

Hello, looking into the code, the documentation, and the proposed standard I can't find a way to output a boost::tuple to a stream with no opening and closing characters??? tuples::tuple_open requires a character, and thus one has to use some opening character, and equally some closing character???? (I can't believe this: Everybody knows that adding strings is much easier than erasing them.) Oliver

2 2

[regex] match_partial and regex_search
by Eric Niebler 20 May '05

20 May '05

I noticed some surprising behavior with match_partial and regex_search. Consider: regex e("abc|b"); string str("ab"); smatch what; if(regex_search(str, what, e, match_default | match_partial)) { cout << (what[0].matched ? "full" : "partial") << '\n'; } This code displays "partial". Clearly, regex_search is bombing out just as soon as it finds a match, partial or otherwise. But in this case, if it kept looking, it would find a full match. My understanding is that full matches are always preferred to partial matches. I couldn't find any discussion about this case in the regex docs or the std proposal. Did I miss it? What's the intention here? Is the std proposal underspecified? -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

[random] Update for better TR1 compliance
by Jens Maurer 20 May '05

20 May '05

I've checked in changes to the Boost.Random library that add constructors and seeding for both template<class Generator> and unsigned long arguments, thereby moving Boost.Random one step further towards TR1 compliance. The random_test.cpp program now has basic tests for this feature. In order to guide overload resolution, I've used boost::enable_if<> and type traits to make sure that integral arguments don't try to call the "template<class Generator>" overloads. This could mean decreased compiler support, sorry. It works for me with gcc 3.4.3. Jens Maurer

5 7

Interest in C function pointer utility?
by Rene Rivera 20 May '05

20 May '05

In rewriting a plugin interface I use, which for language portability uses C function pointers as the entry points, I came up with a "make_c_function" utility. I use it to translate C++ functions, any of objects, binds, function, members, et. to _real_ C function pointers. For example: class P { public: int foo(int); }; P p; extern "C" { void * get_plugin_call(int n) { if (1 == n) { return make_c_function<P,int(int)>( boost::bind(&p,p::foo,_1)); } else { return 0; } } } [example much abbreviated from real life use] -- -- 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 4

[iostreams] patch for examples/dictionary_filter.hpp for bcc32
by Russell Hind 20 May '05

20 May '05

Please find attached a patch for libs/iostreams/example/dictionary_filter.hpp to help get the tests to build under bcc32 5.6.x and STLPort Thanks Russell Index: libs/iostreams/example/dictionary_filter.hpp =================================================================== RCS file: /cvsroot/boost/boost/libs/iostreams/example/dictionary_filter.hpp,v retrieving revision 1.3 diff -u -r1.3 dictionary_filter.hpp --- libs/iostreams/example/dictionary_filter.hpp 20 May 2005 03:59:33 -0000 1.3 +++ libs/iostreams/example/dictionary_filter.hpp 20 May 2005 12:22:17 -0000 @@ -42,7 +42,11 @@ using namespace std; while (true) { int c = std::cin.get(); +#if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) + if (c == EOF || !std::isalpha(c)) { +#else if (c == EOF || !std::isalpha(c, dictionary_.getloc())) { +#endif dictionary_.replace(current_word_); cout.write( current_word_.data(), static_cast<streamsize>(current_word_.size()) ); @@ -84,7 +88,11 @@ if ((c = iostreams::get(src)) == WOULD_BLOCK) return WOULD_BLOCK; +#if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) + if (c == EOF || !std::isalpha(c)) { +#else if (c == EOF || !std::isalpha(c, dictionary_.getloc())) { +#endif dictionary_.replace(current_word_); off_ = 0; if (c == EOF) @@ -127,7 +135,11 @@ if (off_ != std::string::npos && !write_current_word(dest)) return false; +#if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) + if (!std::isalpha(c)) { +#else if (!std::isalpha(c, dictionary_.getloc())) { +#endif dictionary_.replace(current_word_); off_ = 0; } @@ -190,8 +202,13 @@ if (it == map_.end()) return false; string& value = it->second; +#if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) + if (!value.empty() && !key.empty() && std::isupper(key[0])) + value[0] = std::toupper(value[0]); +#else if (!value.empty() && !key.empty() && std::isupper(key[0], loc_)) value[0] = std::toupper(value[0], loc_); +#endif key = value; return true; } @@ -201,7 +218,11 @@ inline void dictionary::tolower(std::string& str) { for (std::string::size_type z = 0, len = str.size(); z < len; ++z) +#if defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) && (__BORLANDC__ <= 0x564) && !defined(_USE_OLD_RW_STL) + str[z] = std::tolower(str[z]); +#else str[z] = std::tolower(str[z], loc_); +#endif } } } } // End namespaces example, iostreams, boost.

2 1

RE: Non-intrusive serialization with VC2003 (7.1) and building from CVS
by Marcin Tustin 20 May '05

20 May '05

It looks a lot like the problem I was having was caused by constness. To be clear, I was doing: template<class Archive> void serialize(Archive & ar, const Jrs::SmartPtr<D2::Message>& g, const unsigned int version) { //... } Now I'm doing: template<class Archive> void serialize(Archive & ar, Jrs::SmartPtr<D2::Message>& g, const unsigned int version) { // ... } The new version does compile, but as I am having problems building boost (from CVS), it doesn't link because the libraries don't exist. It compiles with the CVS version, but still does not compile under 1.32. As to building, I am trying to use the version of bjam I built to build 1.32, running it from the place it was built to: mt@penfold /cygdrive/c/new_boost/boost $ /cygdrive/c/boost_1_32_0/tools/build/jam_src/bin.ntx86/bjam.exe But this cannot create files or directories. Any suggestions?

1 0

[serialization][ptr_container] serialization of ptr_containers
by Felipe Magno de Almeida 20 May '05

20 May '05

Hi, I was trying to serialiaze ptr_containers and I couldnt find a way, so I copied some headers and modified them to serialize ptr_list(the only one I need to serialize in the moment), and it seems to be working. So If someone is interested, I could send it to someone. Im not an expert in the serialize library, so I dont even know if it is really right... But it worked to me(the objects are all serialized as pointers, so if there's two objects then it just serialize one...). I think that extending it to serialize others sequence containers would be very easy, but I didnt touch in the associative containers... The files that I created: ptr_collections_load_imp.hpp // from collections_load_imp.hpp ptr_collections_save_imp.hpp // from collections_save_imp.hpp ptr_list.hpp // from list.hpp Thank you. -- Felipe Magno de Almeida UIN: 2113442 email: felipe.m.almeida+spam at gmail com felipe.almeida+spam at ic unicamp br, felipe.m.almeida at gmail com, felipe+spam at synergy com (Remove the +spam from the email) I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com "There is no dark side of the moon really. Matter of fact it's all dark."

2 1

Re: [boost] Re: Re: char[] support in Boost.Range
by brangdon＠cix.compulink.co.uk 20 May '05

20 May '05

In-Reply-To: <d6dhiu$hai$1(a)sea.gmane.org> technews(a)kangaroologic.com (Jonathan Turkanis) wrote (abridged): > > Are we going to generalise it to allow any (compile-time constant) > > terminator? > > Why does the terminator have to be a compile-time constant? I was hesitant about suggesting a generalisation which added run-time overhead over only supporting '\0'. Also, the need is not very common in my experience. -- Dave Harris, Nottingham, UK.

3 4

RE: [boost] Logging Library -- Formal Review Request
by Spencer.Collyer＠barclayscapital.com 19 May '05

19 May '05

> >Thanks!!! > > > >Also, an application should have multiple levels at the same > time (i.e., > >an app may want to have a different level of debug logging per > >component, library, class, whatever). > >_______________________________________________ > > > > > This is an interesting request, and I assume it'll change the way I > implement multiple levels. > > Is this a desireable feature? What do you all think? > > In other words, if I understand correctly, you want to be able to set > the level of each log (independently of other logs). > In this case, instead of enabling/disabling logs, I can > simply set the > level of the logs -- and have a level called DISABLED (which is > equivalent to disabling one log) Just de-lurking for a moment here, but I'd like to add my vote for a form of this. At my work we have a logging library that has concepts of log topics and log levels. These are orthogonal - any particular log message is associated with one topic and has one level, but the messages for a given topic can have any level specified. The topics are arranged in a tree-like hierarchy, and if a minimum logging level is specified for a topic it also affects any subtopics of that topic which have not had a logging level specifically set. This allows us to easily tune the amount of logging information produced so that only the items we are specifically working on get logged at a high debugging level, without interference from components we are not interested in. This makes tracking problems considerably easier, as only the relevant information is output. Just my twopen'orth. S> ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------

2 1

RE: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 19 May 2005 16:34 > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1) > > Marcin Tustin wrote: > > c:\new_boost\boost\boost\archive\detail\oserializer.hpp(152) : > > > The choice is made here. Yes, and for the moment my understanding of function selection in C++ is not enough to understand why the choice is made. > >>>> namespace boost { > >>>> namespace serialization { > >>>> template<class Archive > > >>>> static void serialize(Archive & ar, const > >>> D2::Message& g, const > >>>> unsigned int version) > >>>> { > >>>> //... > >>>> } > >>>> > >>>> } }; > >>>> > > Note that your serialize template above uses datatype > D2::Message while one is trying to serialize D2::MessagePtr. I've changed the function to use D2::MessagePtr already. The move to D2::MessagePtr (Which is a typedef for Jrs::SmartPtr<D2::Message>) is for other reasons. In any case, the problem still obtains. The new code is: template<class Archive> void serialize(Archive & ar, const Jrs::SmartPtr<D2::Message>& g, const unsigned int version) { //ar & g.stdString(); ar & g.px; // contained pointer ar & g.pn; // reference counter } And yes, I am aware that there is a whole load of extra complexity in correctly serialising smart pointers, and I will deal with that once I can get any non-intrusive serialisation to work. Thanks again for your help and attention.

1 0

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Jason Earl [mailto:Jason@hybd.net] > Sent: 19 May 2005 16:20 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > I'm probably completely wrong, but but am I right in thinking > the problem is due Jrs::SmartPtr<T> and not the fact that > VS.NET or the serialization library is not find the right > serialize method. If so I'm surprised no one else has pointed > this out before! The big deal is that there is a non-intrusive serialize function (i.e. an external function) rather than a method on SmartPtr. The problem is that this function is not being detected, so the template library falls through to trying to use a serialize method, which does not exist. Because I'm building on another library, there is no possibility of going over to any other kind of smart pointer.

1 0

RE: [boost] Logging Library -- Formal Review Request
by Spencer.Collyer＠barclayscapital.com 19 May '05

19 May '05

> > At my work we have a logging library that has concepts of > log topics and > > log levels. These are orthogonal - any particular log message is > > associated with one topic and has one level, but the messages for a > > given topic can have any level specified. The topics are > arranged in a > > tree-like hierarchy, and if a minimum logging level is > specified for a > > topic it also affects any subtopics of that topic which > have not had a > > logging level specifically set. > > I would assume what you call "topic" here, is what I've done by using > loggers/hierarchy. Have you read the docs? John, what we call topics are indeed analogous to your loggers. I have indeed read the docs and found a lot to like in the proposed library, but it does need the ability to specify different levels for different messages on a particular log (IMHO, of course :) ) Spencer ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------

1 0

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

I've been looking through the template instantiation trace, and I can't figure out where the choice to use the intrusive mechanism is made. I'll keep looking a little more, and I've appended the trace below: ------ Build started: Project: NewClient, Configuration: Debug Win32 ------ Compiling... EnhancedMessageHandler.cpp c:\D2\API\NewClient\EnhancedMessageHandler.cpp(151) : warning C4244: '=' : conversion from 'uintptr_t' to 'unsigned long', possible loss of data c:\new_boost\boost\boost\serialization\access.hpp(107) : error C2039: 'serialize' : is not a member of 'Jrs::SmartPtr<T>' with [ T=D2::Message ] c:\new_boost\boost\boost\serialization\serialization.hpp(81) : see reference to function template instantiation 'void boost::serialization::access::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\serialization\serialization.hpp(140) : see reference to function template instantiation 'void boost::serialization::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(152) : see reference to function template instantiation 'void boost::serialization::serialize_adl<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\serialization\extended_type_info_typeid.hpp(71) : while compiling class-template member function 'void boost::archive::detail::oserializer<Archive,T>::save_object_data(boost:: archive::detail::basic_oarchive &,const void *) const' with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(236) : see reference to class template instantiation 'boost::archive::detail::oserializer<Archive,T>' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(235) : while compiling class-template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard: :invoke(Archive &,const Jrs::SmartPtr<D2::Message> &)' with [ Archive=boost::archive::text_oarchive, T=D2::MessageP tr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(294) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard ' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(282) : while compiling class-template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::invoke(Archive &,const Jrs::SmartPtr<D2::Message> &)' with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(534) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\basic_text_oarchive.hpp(78) : see reference to function template instantiation 'void boost::archive::save<Archive,T>(Archive &,T &)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\interface_oarchive.hpp(89) : see reference to function template instantiation 'void boost::archive::basic_text_oarchive<Archive>::save_override<T>(T &,int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\D2\API\NewClient\EnhancedMessageHandler.cpp(115) : see reference to function template instantiation 'Archive &boost::archive::detail::interface_oarchive<Archive>::operator <<<const D2::MessagePtr>(T &)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ]

3 2

[iostreams] example_test and newline_test loop on gcc-3_3-darwin
by Douglas Gregor 19 May '05

19 May '05

The iostreams example_test and newline_test seem to be looping. I've killed them on the OSL tester, but now symmetric_filter_test is currently taking a really long time to run... with the exception of newline_test (which has been failing for a while), all of these tests were passing before yesterday's flurry of iostream modifications. Doug

5 19

Big integer library
by Marcin Kalici�ski 19 May '05

19 May '05

Tracking the disussion on n1774 'Big integer library proposal for C++0x' I see there is a lot of controversy about it, and it will probably need much tweaking before (if ever) it is accepted. Wouldn't that be a good idea to have a big integer added to boost so that we can create a 'working practice' before anything gets standarised? I have some preliminary source code, some spare time, and would volunteer to work on it if there's enough interest. cheers, M.

11 10

[Iterator] advance and distance that understand new iterator concepts?
by Douglas Gregor 19 May '05

19 May '05

Do we have counterparts to std::advance and std::distance that are optimized for random_access_traversal_tag instead of std::random_access_iterator_tag? Doug

2 1

[Wave] Boost Inspection Report
by Hartmut Kaiser 19 May '05

19 May '05

Hi all, the boost inspection report claims that one of the Wave test files contains tabs. And this is correct! But: it needs to contain tabs because it's a testcase... Should I ignore this warning? Or is there a way to tell the inspect program to ignore tabs in this particular file? Regards Hartmut

4 10

xpressive not in boost.1.33, but what about 1.34?
by Bronek Kozicki 19 May '05

19 May '05

I suppose xpressive has not been accepted into boost yet (or I missed library review). This would mean that we will not see it in boost 1.33. Is there any chance we would see it in boost 1.34? B. -- Bronek Kozicki brok(a)rubikon.pl http://b.kozicki.pl/

8 13

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 18 May 2005 16:54 > To: boost(a)lists.boost.org > Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > By extensive error trace I mean the whole chain of > instantiations with lines like "instanciated from" ... > Sometimes this chain is dozens of lines long. Its the > compile-time version of a call stack. This can be used to > trace back through the chain of calls to determine which one > didn't work as expected. How do I access this trace? I've never seen such a thing. > Robert Ramey > > > Perhaps I don't know enough about VC 7.1, but what > extensive error > > trace? > > > > c:\new_boost\boost\boost\serialization\access.hpp(107): error C2039: > > 'serialize' > >> is not a member of 'Jrs::SmartPtr<T>' > > with > > [ > > T=D2::Message > > ] > > > > is all that I get. I can't begin to imagine how I would go about > > diagnosing the cause of the error. > > > > > > >

2 1

[Boost-bugs] [ boost-Bugs-1204688 ] Document copy_component
by SourceForge.net 19 May '05

19 May '05

Bugs item #1204688, was opened at 2005-05-18 21:18 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=1204688&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: Document copy_component Initial Comment: It's in boost/graph/copy.hpp, and useful, so we should document it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204688&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1204684 ] random_vertex/random_edge are unnecessarily inefficient
by SourceForge.net 19 May '05

19 May '05

Bugs item #1204684, was opened at 2005-05-18 21:12 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=1204684&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: random_vertex/random_edge are unnecessarily inefficient Initial Comment: random_vertex and random_edge should require constant time for RandomAccessTraversal iterator, but they are still linear time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1204684&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[operators] Improved workaround for BOOST_NO_OPERATORS_IN_NAMESPACE
by Daniel Frey 18 May '05

18 May '05

A new version of operators.hpp is available in the sandbox at <http://boost-sandbox.sourceforge.net/vault/index.php?&directory=daniel_frey>, it contains an improved workaround for compilers that need BOOST_NO_OPERATORS_IN_NAMESPACE. Other compilers should not be affected, but hey, you never know :) I'd like to ask for people to test the new version. In particular, the following compilers set BOOST_NO_OPERATORS_IN_NAMESPACE in their config-files (see boost/config/compiler/...) for some versions: - GCC < v3 - Borland - Digital Mars - ACC (hp_acc) If you (still) have one of these compiler with the affected versions, please test the new operators.hpp. Besides running the regression tests, which obviously must work, you can try to compile the following examples with the old and the new version: Example1.cpp: #include <boost/operators.hpp> using namespace boost; class a:addable1<a>{ public: a& operator+=(const a&){return *this;}; }; int main(){ } Example2.cpp: #include <boost/operators.hpp> bool addable1; int main(){ } Both examples previously failed to compile on (some of?) the compilers that had BOOST_NO_OPERATORS_IN_NAMESPACE defined, the new version should fix that. Also, reviews of the patch are also welcome. One final note: The new version will not go into 1.33.0, which is why I choose to put the new version in the sandbox first. Once 1.33.0 is out and given that the initial tests look positive, it will go into CVS to make sure the full regression testing is applied and the regression test will be improved to check for the above examples. Out of curiousity: Will the new version (with the appropriate define set) improve the situation for the VC7? Anyone care to check that, too? (If it shows an improvement, I honestly have no clue why ;) Thanks for you time. Regards, Daniel

1 0

RE: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 18 May '05

18 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 16 May 2005 16:30 > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1) > > Note the "long int hack" isn't used with vc 7.1 as it support > correct partial template ordering. Interesting. Still doesn't explain why the compiler is trying to use the intrusive stuff, rather than the non-intrusive layer, at least to my relatively unschooled C++ mind. Is there anything I should do, or should I try something like writing wrapper classes for everything? > Marcin Tustin wrote: > >> -----Original Message----- > >> From: Robert Ramey [mailto:ramey@rrsd.com] > >> Sent: 13 May 2005 15:51 > >> To: boost(a)lists.boost.org > >> Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > >> > >> Try putting your function inside the namespace D2 > > > > I did. I also tried putting it in the global namespace. Same error. > > > >> Robert Ramey > >> > >> Marcin Tustin wrote: > >>> I'm trying to use the serialization and archive > libraries, and I'm > >>> having a bit of trouble getting non-intrusive serializaton > >> to work; I > >>> keep getting the error > >>> "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: > >>> 'serialize' : is not a member of 'D2::Message'". My guess > >> is that for > >>> some reason the "long int" hack isn't working properly. I have > >>> serialize methods in the boost::seralization namespace like this: > >>> > >>> namespace boost { > >>> namespace serialization { > >>> template<class Archive > > >>> static void serialize(Archive & ar, const > >> D2::Message& g, const > >>> unsigned int version) > >>> { > >>> //... > >>> } > >>> > >>> } }; > >>> > >>> Which are textually before any use of the library, as far > as I can > >>> tell. > >>> > >>> Any help would be much appreciated. > >>> > >>> Marcin Tustin > >>> IT Innovation Centre > >>> 2 Venture Road > >>> Chilworth Science Park > >>> Southampton, SO16 7NP, UK > >>> > >>> tel: +44 23 8076 0834 > >>> fax: +44 23 8076 0833 > >>> > >>> mailto:mt@it-innovation.soton.ac.uk > >>> http://www.it-innovation.soton.ac.uk > >>> > >>> _______________________________________________ > >>> Unsubscribe & other changes: > >>> http://lists.boost.org/mailman/listinfo.cgi/boost > >> > >> > >> > >> > >> > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > >

2 4

[python] Patch for Tru64/cxx
by Markus Schöpflin 18 May '05

18 May '05

Attached patch allows the python library to successfully build on Tru64/cxx65. Ok to commit? Markus Index: registry.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/python/src/converter/registry.cpp,v retrieving revision 1.28 diff -u -w -r1.28 registry.cpp --- registry.cpp 16 May 2005 03:31:12 -0000 1.28 +++ registry.cpp 18 May 2005 09:41:25 -0000 @@ -161,11 +161,13 @@ assert(slot == 0); // we have a problem otherwise if (slot != 0) { - std::string msg( - "to-Python converter for " - + lexical_cast<std::string>(source_t) - + " already registered; second conversion method ignored." - ); + std::string msg("to-Python converter for "); +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) + msg += source_t.name(); +#else + msg += lexical_cast<std::string>(source_t); +#endif + msg += " already registered; second conversion method ignored."; if ( ::PyErr_Warn( NULL, const_cast<char*>(msg.c_str()) ) ) {

2 2

Why protect()?
by alex 18 May '05

18 May '05

I test the sample in the section "Nesting STL algorithm invocations": -------------------------------------- int a[100][200]; int sum = 0; std::for_each(a, a + 100, bind(ll::for_each(), _1, _1 + 200, protect(sum += _1))); ------------------------------------------------If I remove the protect function, and I will get a complie error.Thx!

2 1

program_options version
by Janusz Piwowarski 18 May '05

18 May '05

Hi, I think that BOOST_PROGRAM_OPTIONS_VERSION should be incremented in 1.33 release. Regards, Janusz

1 0

[serialization] problems in Comeau
by Joaquín Mª López Muñoz 18 May '05

18 May '05

Boost.Serialization is currently failing to build in Comeau 4.3.3, apparently for legitimate reasons: http://tinyurl.com/adv2g The detail type helper_type in libs/serialization/src/basic_oarchive.cpp contains the following member: const boost::serialization::extended_type_info * const m_eti; whose constness prevents the compiler from generating a default assignment operator for helper_type. Hence helper_type is not Assignable and thus cannot be used in a STL container like attempted at line 164 in the same archive: std::set<helper_type, helper_compare> m_helpers; I guess removing the const qualifier of m_eti would suffice to make this error go away. Any objection to me applying the attached patch (confirmed to work on MSVC, yet untested in Comeau)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 143c143 < const boost::serialization::extended_type_info * const m_eti; --- > const boost::serialization::extended_type_info * m_eti; 146c146 < const boost::serialization::extended_type_info * const eti --- > const boost::serialization::extended_type_info * eti

2 1

Re: [boost] Re: Re: Re: char[] support in Boost.Range
by dan marsden 18 May '05

18 May '05

> Anyway, that wasn't my point. My point was that > it is really easy to get the array behavior if you > want it. > > The only part missing is direct support in the range > library > to trigger array behavior for range arguments, say > as_array(). It seems strange to need to force the more basic behaviour of an unconstrainted array of chars with zero cost for establishing the bounds, and default to higher level behaviour implying a delimiter and a linear cost to calculate the bounds. Some of this depends on what you perceive as the common case, but the differing behaviour between char[N] and MyType[N] presents a lack of uniformity that could hurt generic code developers and confuse users. Dan ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

4 5

operators.hpp bugs
by Søren Lassen 17 May '05

17 May '05

I have found a couple of "undocumented features" in operators.hpp: 1) The return values from a lot of the binary operators should be declared const, so that it is not possible to assign to the temporary object that results from the operation. An example: if(!(a/b=c/d))... This statement is obviously a typo. The assignment operator= should have been a comparison operator==. With the current definition of operator/ in operators.hpp, the compiler will not recognize this as an error. Instead, the following will happen: first, the values of a/b and b/c are calculated and placed in temporary objects. Then, the result of a/b is overwritten by the result of c/d. Finally, operator! converts that to a boolean and the if statement acts on it (in other words, the statement is probably interpreted as "if(!c)..."). If, on the other hand, the return value from operator/ is declared constant, the compiler will catch the error, and probably say something like "lvalue required". Much better. 2) I think the "Named Return Value Optimization" code is a misunderstanding. The way I read the excerpts from the C++ standard quoted in the documentation (see http://www.boost.org/libs/utility/operators.htm#symmetry) is as follows: The standard places some limits on when NAMED objects may be optimized away. From this follows implicitly that UNNAMED objects may always be optimized away. Or, to quote from Scott Meyers' "More Effective C++", page 109-110: "However, the fact remains that unnamed objects have historically been easier to eliminate than named objects, so when faced with a choice between a named object and a temporary object, you may be better off using the temporary. It should never cost you more than its named collegue, and, especially with older compilers, it may cost you less". In other words: some compilers may not have Named Return Value Optimization, but most of them have (Unnamed) Return Value Optimization, which means that temporary, unnamed objects are optimized away where possible. So, I think, a better way of writing e.g. operator+ is the good old-fashioned: template <class T> inline const T operator+(const T& lhs,const T& rhs) {return T(lhs) += rhs;}; 3) When using compilers that do not support operators in namespaces (#ifdef BOOST_NO_OPERATORS_IN_NAMESPACE), the operator templates are first placed in the global namespace, and then copied to the boost namespace. The consequence of this is that it is not possible to access the templates with a "using namespace boost;" declaration - trying to do so creates an ambiguity between the stuff in boost and the stuff in the global namespace. Also, of course, the global namespace is "polluted" with quite a lot of extra names. The solution to this problem is to declare all the templates inside a "pseudo-namespace" struct in the global namespace - this also makes it easier to import the templates into boost, as even the Borland compiler now recognizes a "using" declaration. I have uploaded a new version of "operators.hpp" with fixes for above-mentioned problems to the sandbox vault. It has been tested with "rational.hpp" on the Borland 5.5 compiler and the Microsoft version 13.10.3077 compiler (the one that comes with the free Visual Toolkit 2003, and also (I think) with Visual C++ 7.1). I hope that some of you have time to test my new version with other programs and compilers. --- Søren

5 20

char[] support in Boost.Range
by Pavol Droba 17 May '05

17 May '05

Hi Boosters, There was a discussion about char[] support in the Boost.Range library. The issue seems important and I'd like to express my ideas about a possible solution. First lets sumarize problems and goals. The problems: char[] and possibly any other type that can be used as a c-string (this includes wchar_t, but also int, long and etc when used as a unicode code-point) might represent two different things: 1.) c-string literal 2.) arbitrary c-array Both views differ in lenght calculation, which is totaly incompatible and what's worse, it can lead to casual access violation when used improperly. An example: char str[] = "Hello"; // typeof(str) is char[6], str=={'h','e','l',l','o',0} In the c-string view, str have 5 letters and ends at the 'o'. So the range should be <'H','o') In c-array view str is 6 elements long and ends with '\0' The range is <'H','\0') From the user perspective, both views are equaly important, however according to the usage scenarion, one might be preferable over the other one. Important aspect to keep in mind is this strict relativnes. For example for string algorithms c-string literal is obvious default, while for a data processing library the second choice is better. Current implementation is not ideal. First of all, there is a difference between char,wchar_t[] and the rest of the types. This brings some confusion. Secondly, it is not possible to use char[] as an ordinary array. The goals: From the problem analysis above, following goals can be implied 1. we need to support both views equaly 2. a user must be always able to explicitly specify what type of view he requires 3. it should be possible for a library writer to select default view for his library. However point (2) must hold, so the user must be able to override this default. 4. Support must be present in the Boost.Range library. It is not feasible to ask library writer to provide specific workarounds/hacks. It would simply break the idea of Boost.Range library as a unified interface to range-like data structures. The solution: I propose to have two free-standing functions as_string() and as_array() (naming is not important now). Both should have the same generic signature: template<typename RangeT> boost::sub_range<RangeT> as_string(RangeT& aRange); template<typename RangeT> boost::sub_range<RangeT> as_array(RangeT& aRange); By default, the functions only copy the input range to the target. However for the types like char[], the result will differ. For as_string() will create a sub_range delimiting string literal (using char_type<char>::length for instance), while as_array() will use compile-time boundaries. In addition we might consider to open this interface for user-defined type, even if I'm not sure how it can be used. Please note, that once any of these manipulators is applied to a range following application will have no effect. Lets see how this faicility can be used: A library writer can set the default by writting algorithm like this: template<typename RangeT> ... AnAlgorithm(const RangeT& aRange) { boost::sub_range<RangeT> StrRange=as_string(aRange); // Do something with StrRange } If a user calls AnAlgorithm directly: char str[]="hello"; AnAlgorithm(str); str will be converted to a range, delimiting a string_literal. However he can alse use as_array(): char str[]={'h', 'e', 'l', 'l', 'o'}; AnAlgorithm(as_array(str)); This time no conversion will take place, since as_array() returns sub_range. Note, that for the AnAlgorithm it does not matter what default is used in the Range library. Open questions: - I have intentionaly not included a proposal for the default view that the Range library should provide. Goal of this solution is to provide a way, that is not dependant on this. I'd like to leave it for the discussion. Right now it seems, that most of the people that entered discussion prefer c-array view. I would prefer c-string view, but I'm probably biased by the fact that I'm the author of StringAlgo library. - There is a space for possible extentions to the basic proposal. For instance, as_string() migh have the second parameter that will identify a terminator. - String literal lenght can be calculated in two ways. Either by using strlenght() (or alike), or using compile-time size (N) decreased by 1 (N-1). Later approach is faster and allows to specify literals like this: char str[]="hello\0bye"; But it is different from char* handling and therefor it might be confusing. Best Regards, Pavol

6 15

[preprocessor] What syntax to present to the user
by Loïc Joly 17 May '05

17 May '05

Hello everybody, I'm trying to use the boost preprocessor library to allow the user to define "rich" enums, for instance enums that cannot be converted to int, whose values can be displayed in human readable form on a stream... I think I have to use macro to ease the writing of such enums, and I decided it was a good occasion to learn boost::preprocessor. My first impression : Wow ! You guys really use magic when programming ! Now, I have to decide what will be the interfaces for such rich enums. My (unreachable) goal would be something like that : RichEnum Type{Val1, Val2, Val3}; A little bit more reasonnable (but still unacheivable, I believe) goal would be : RICH_ENUM(Type, Val1, Val2, Val3); I think I can come up with several possible writing : 1/ RICH_ENUM(Type, (Val1)(Val2)(Val3)); 2/ RICH_ENUM(Type, 3, (Val1,Val2,Val3)); 3/ #define NAME Type #define VALUES (Val1)(Val2)(Val3) #include "RichEnum.h" #undef NAME #undef VALUES 4/ same as 3/, but with tuple syntax for VALUES With 1/ and 2/, all the class declaration is on the same line, which could decrease debugability. With 3/ and 4/, I can write it one several lines. And now, the questions : Which writing do you think would be best ? Why ? Are there other possibilities I overlooked ? Is is possible to have a syntax like 1/ and 2/ with good debugability ? Regards, -- Loïc

2 3

Re: [boost] Re: char[] support in Boost.Range
by brangdon＠cix.compulink.co.uk 17 May '05

17 May '05

In-Reply-To: <20050516205339.GW11789(a)lenin.felcer.sk> droba(a)topmail.sk (Pavol Droba) wrote (abridged): > In addition I would suggest to remove direct support for pointer types > like char* from the range library and provide it only via as_string() > construct to definitely remove any kind of confusion. Sounds like a good idea. Are we going to generalise it to allow any (compile-time constant) terminator? If so, is as_string() the best name? -- Dave Harris, Nottingham, UK.

3 2

Re: [boost] Re: Re: char[] support in Boost.Range
by dan marsden 17 May '05

17 May '05

> > what's wrong with using boost::array<char,N> for all > this? > > -Thorsten > If boost::array<char,N> is not going to behave the same at char[N] in this respect surely that is counter intuitive? Wasn't there a fixed string type under consideration that could be applied the opposite way? ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

2 1

[wave] cw-8.3 segfault..
by Rene Rivera 17 May '05

17 May '05

Hartmut, Don't know is this will help at all.. But this is the stack trace for the crash for testwave built with CW-8.3: ========== > testwave.exe!boost::spirit::multi_pass_policies::buf_id_check::check() const(buf_id_check * this=0xcccccccc) Line 195 + 0xb C++ testwave.exe! ?? ?? :: ?? ::operator*(multi_pass * this=0x0012eb0c) Line 1005 C++ testwave.exe!?get@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_po(iteration_policy * this=0x0012eb40, scanner & scan={...}) Line 50 + 0xb C++ testwave.exe! ?? ?? :: ?? ::operator*(scanner * this=0xcccccccc) Line 251 + 0xb C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(char_parser * this=0xcccccccc, scanner & scan={...}) Line 50 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(kleene_star * this=0xcccccccc, scanner & scan={...}) Line 58 + 0x19 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(sequence * this=0xcccccccc, scanner & scan={...}) Line 54 + 0x16 C++ testwave.exe! ?? ?? :: ?? ::do_parse_virtual(concrete_parser * this=0x0012ed30, scanner & scan={...}) Line 233 + 0x11 C++ testwave.exe!?parse_main@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_m(rule_base * this=0x00138078, scanner & scan={...}) Line 189 + 0x19 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(rule_base * this=0xcccccccc, scanner & scan={...}) Line 172 + 0x48 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(optional * this=0xcccccccc, scanner & scan={...}) Line 54 + 0x16 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(sequence * this=0xcccccccc, scanner & scan={...}) Line 54 + 0x16 C++ testwave.exe!?do_parse_virtual@?$concrete_parser@U?$sequence@U?$sequence@U?$alternative@U?$alternative@U?$chlit@W4token_id@wave@boost@@@spirit@boost@@U?$pattern_and@W4token_category@wave@boost@@@util@wave@3@@spirit@boost@@U?$pattern_and@H@util@wave@3@@spirit@boost@@U?(concrete_parser * this=0x0012eebc, scanner & scan={...}) Line 233 + 0x11 C++ testwave.exe!?parse_main@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_m(rule_base * this=0x00138070, scanner & scan={...}) Line 189 + 0x19 C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(rule_base * this=0xcccccccc, scanner & scan={...}) Line 172 + 0x48 C++ testwave.exe!?do_@?$@V?$tree_match@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@V?$node_val_data_factory@Unil_t@spirit@boost@@@spirit@4@Unil_t@(tree_match & result={...}, definition & def={...}, scanner & scan={...}) Line 262 + 0x16 C++ testwave.exe!?grammar_parser_parse@?$@$0A@Upredefined_macros_grammar@grammars@wave@boost@@U?$parser_context@Unil_t@spirit@boost@@@spirit@4@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave(grammar * self=0x0012f058, scanner & scan={...}) Line 281 + 0xf C++ testwave.exe!?parse_main@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_m(grammar * this=0x0012efec, scanner & scan={...}) Line 55 + 0x1f C++ testwave.exe!?parse@?$@V?$scanner@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@U?$scanner_policies@Uiteration_policy@spirit@boost@@U?$pt_match_(grammar * this=0xcccccccc, scanner & scan={...}) Line 63 + 0x48 C++ testwave.exe!?pt_parse@?$@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@@@cpplexer@wave@boost@@@cpplexer@wave@boost@@Upredefined_macros_grammar@grammars@34@@spirit@4@YA?AU?$tree_parse_info@(lex_iterator & first_={...}, lex_iterator & last={...}, parser & parser={...}) Line 229 C++ testwave.exe!boost::wave::grammars::predefined_macros_grammar_gen<class boost::wave::cpplexer::lex_iterator<class boost::wave::cpplexer::lex_token<struct boost::wave::util::file_position<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > > >::parse_predefined_macro( ?? )(lex_iterator & first={...}, lex_iterator & last={...}) Line 153 + 0x13 C++ testwave.exe!?add_macro_definition@?$@V?$context@V?$__wrap_iterator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PB$$CBD@std@@V?$lex_iterator@V?$lex_token@U?$file_position@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@util@wave@boost@(context & ctx=, basic_string & macrostring=, bool is_predefined=, language_support language=) Line 154 + 0x4a C++ ========== All those this=0xcccccccc, is CodeWarrior's way of saying one has a refenrence to a deleted object. As that's the value it clears memory to when it deletes. -- -- 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 7

[1.33] Program_options and Borland
by John Maddock 17 May '05

17 May '05

The following patches get Boost.Program Options compiling with Borland C++ 5.6.4 (it's enough to fix the regex grep test program which was what I wanted). Is it OK to apply these? I can't see how they would cause problems with other compilers: in fact I'm not at all clear how "cmdline" was ever found without the qualifier on other compilers. I haven't looked at the runtime test failures with this compiler yet (has anyone?), Regards, John. RCS file: /cvsroot/boost/boost/boost/program_options/detail/parsers.hpp,v retrieving revision 1.7 diff -r1.7 parsers.hpp 31c31 < : cmdline(to_internal(args)) --- > : detail::cmdline(to_internal(args)) 38c38 < : cmdline( --- > : detail::cmdline( 49c49 < cmdline::set_options_description(desc); --- > detail::cmdline::set_options_description(desc); 59c59 < cmdline::set_positional_options(desc); --- > detail::cmdline::set_positional_options(desc); 67c67 < cmdline::style(style); --- > detail::cmdline::style(style); 75c75 < cmdline::set_additional_parser(ext); --- > detail::cmdline::set_additional_parser(ext); 84c84 < result.options = cmdline::run(); --- > result.options = detail::cmdline::run();

2 2

boost::program_options INI file parsing
by Preston A. Elder 17 May '05

17 May '05

The INI file parser module of program_options needs to be changed. For some reason, the comment delimiter has been changed from ';' to '#'. The bigger problem is this has been taken beyond the first character of the line and there is no escaping ability! The more common INI file comment behavior is: '#' is a comment ONLY if it is the first character of the line ';' is a comment from that point of the line on, unless preceeded by a '\' (or more accurately, an odd number of '\' characters, since you could theoretically do \\\;, to translate to \; when made a string). I have written my own INI parser for my own purposes, but it is not associated with program_options, which makes its usefulness in that context limited (without a lot of extra coding, etc). You can view the source here: http://www.neuromancy.net/viewcvs/Mantra-I/src/file/inifile.cpp?root=mantra… My own implementation does differ from the standard INI file parsing convention in allowing line continuation, ie. Allowing: my_option = some text \ some more text And it is interpreted as 'some text some more text'. One big selling point of my implementation is that it uses boost::spirit (the lexical parser) to do the parsing - so the logic for parsing is encoded in the lexical parsing language, not in code. Theoretically, this means you should be able to use my implementation directly, and adapt the code from IniFile::Load() that uses it for program_options relatively easily, and not have to worry about the parsing logic itself. Otherwise (if you don't want to use a lexical-parser based implementation, or my version specifically), could we please stick to the standards, and allow '#' as a comment ONLY from the beginning of the line, and then ';' from any point in the line (as '#' is treated in the current version) (with the 'escaping' rules). Thanks, -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

6 7

[ptr_container] and bcc32
by Russell Hind 17 May '05

17 May '05

I'm trying the regression tests on bcc32 5.6.4. The first error (and often occuring one with bcc32) is in detail/static_move_ptr.hpp line 70 should be changed from static_move_ptr( const move_ptrs::move_source<static_move_ptr>& src ) to static_move_ptr( const move_ptrs::move_source<static_move_ptr<T, Deleter> >& src ) The next is in detail/reversible_ptr_container.hpp line 117 where typedef null_clone_allocator<allow_null> null_cloner_type; needs to be typedef null_clone_allocator<reversible_ptr_container::allow_null> null_cloner_type; The next is in ptr_vector.hpp line 43: BOOST_PTR_CONTAINER_DEFINE_NON_INHERITED_MEMBERS( ptr_vector, needs to be BOOST_PTR_CONTAINER_DEFINE_NON_INHERITED_MEMBERS( ptr_vector<T,CloneAllocator,Allocator>, And the same in ptr_deque. I guess this is the same for the other ptr_XXXX.hpp files (list,set,map etc). The next error I'm not so sure on is in tutl.cpp line 233: tut1.cpp: Error E2227 tut1.cpp 233: Extra parameter in call to boost::ptr_deque<animal,boost::heap_clone_allocator,_STL::allocator<void *> >::release() in function farm::sell_animal(boost::void_ptr_iterator<_STL::_Deque_iterator<void *,_STL::_Nonconst_traits<void *> >,animal>) Error E2034 tut1.cpp 233: Cannot convert '_STL::auto_ptr<boost::ptr_deque<animal,boost::heap_clone_allocator,_STL::allocator<void *> > >' to 'boost::ptr_container_detail::static_move_ptr<animal,boost::ptr_container_detail::clone_deleter<boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<animal,_STL::deque<void *,_STL::allocator<void *> > >,boost::heap_clone_allocator>::null_clone_allocator<0> > >' in function farm::sell_animal(boost::void_ptr_iterator<_STL::_Deque_iterator<void *,_STL::_Nonconst_traits<void *> >,animal>) Cheers Russell

2 13

RE: [boost] Re: Math constants - updated.
by Simon Li 17 May '05

17 May '05

> > On the other hand, the boost libraries have never, as far as I can > > tell, compromised on interfaces to accommodate programmers > who don't > > like templates or modern C++ idioms. [...] > > Why should the constants library be any different? Why should boost > > give physicists special consideration that most C++ > programmers do not > > get? > > There is nothing extraordinary about it. A library is > designed for clients, and it's sound to listen to what they > desire. If they don't like the product, they'll use > something else. That may or may not matter to you. > True, but a library should also be consistent within itself. The impression I get from Boost is that, as pointed out above, it tries to apply strong principals in the design of its interfaces. It also seems to have no qualms (and arguably makes a point) about using relatively recent c++ features (eg. template specialisations) rather than getting bogged down with established practice. IMHO if a user wanted a library using long established programming practice, they definitely wouldn't be using Boost. However, if for some reason someone really did want the constants library, they'd be free to rewrite it (and even release it) in a format they required... it's not as if the values of constants are likely to change :-) Simon This e-mail message (including its attachments) is private, is intended for the recipient named in it and may contain material which is confidential and privileged. No-one other than the named recipient may read, copy, rely on, redirect, save or alter the message or any part of it or any attachment to it in any way. VMS does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not represent those of VMS unless otherwise specifically stated. While reasonable effort has been made to ensure this message is free of viruses, opening and using this message is at the risk of the recipient.

1 0

[program_options] options_description errors..
by Rene Rivera 17 May '05

17 May '05

For CW-8.3 the program_options DLL doesn't build. The stated reason is because of the missing locale support in the DLL configuration. But the error shown doesn't match that: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/dc7mz Which looks like a real problem. It's caused by this line in: const unsigned m_line_length; In the boost::program_options::option_description class. I don't what the intent is for having a const non-static member so I'm not sure how to fix this. -- -- 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

2 1

[static_assert] Problems with CodeWarrior 8.3
by Rene Rivera 17 May '05

17 May '05

While investigating this test failure.. http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/93yz9 Which is a compile-fail test, but compiles successfully with CW-8.3. I narrowed the problem down to this minimal test.. #include <boost/static_assert.hpp> template <std::size_t N> void foo_p() { BOOST_STATIC_ASSERT(N < 3); } int main() { foo_p<5>(); } ..Which compiles without problems. The static_assert code is simple enough so I'm somewhat at a loss here. Don't know how many other tests this affects but it seems kind of important to fix this. So any ideas on what sort of feature/bug this is hitting would be appreciated ;-) -- -- 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

4 16

Singleton: review
by Gennadiy Rozental 16 May '05

16 May '05

Hi, I know I am slightly late but I am quite busy lately. Problem domain ============ Singleton is just a glorified global variable ( (c) Peter Dimov). Singleton is an old pattern. Used quite frequently. But... from my experience it's really bad idea to try to manage an order of destruction of global variables. Any responsible library designers should prefer explicit teardown procedure. There are many reasons for that from general to specific technical issues, i.e: * class destructors preferably shouldn't be doing anything smart * if teardown procedure is not trivial it's part of normal program flow and should reside within main() bounds * it doesn't seem to be ever portable to rely on order of global variables destruction in different libraries (dynamic or static) * it's unreasonable to expect all global variables to employ single manager facility within bound any reasonably big application * if any teardown procedure fails it's really non-trivial to insure proper destruction for the rest of globals (if possible at all), while reporting an error may be impossible/difficult And so on. Taking attempts to manage destruction order out of the picture we have three known techniques to implement singleton: * don't use any objects at all. use free functions in some namespace with static object in implementation namespace log { void print(...) }; * inline static T& log() { static T inst; return inst; } * inline static T& log() { static T* inst = 0; if(!inst) inst = new inst; return *inst; } should cover majority of users needs. They do not need to be formalized in a form of the library but just could exist in a form of reusable idioms. Specific need could easily be achieved by little variations. Design ===== PBD is not about supplying implementation as template parameter and any kind of "super policies" are never a good idea IMO. They trying to bring simplicity of single template parameter, but does not really bring anything. In trivial cases (use all defaults) design with orthogonal polices is as simple. While any customization attempt immediately shows an advantage of later is more convenient and straightforward. For example if I want to use custom locking policy with submitted singleton I would write: class A : singleton_ex<static_lifetime_ex<instant_creation,my_lock> > {...}; Here I not only need to mention default creation policy, but also strange beast static_lifetime_ex. And I only needed custom lock: class A : singleton<lock<my_lock> > {} ----------------- Inability of the author to clearly recognize orthogonal policies lead to 2 subpolicies with "create" in their name: CreationPolicy and Creator. In addition some instances of a Creator take responsibilities of CreationPolicy. For example assert_creator clearly used to manage *when* to create not *how*. The same with throw_.. and null_... The rest of a "Creator"s are also a misplaced efforts. I do not see why would anyone would need to employ malloc or std::allocator to allocate memory for global variable. In most case it's done once per program lifetime. some contrived phoenix singletons with performance requirements seems to have contradicting design goals and I do not see a need for generic support. Most interesting is that among all of these "creators"/creation_policies I don't see a solution for singleton with non-default constructor. ----------------- Singletons very frequently are the bottleneck of program performance. Any singleton solution couldn't afford significant performance overhead. Submitted design clearly leads to some rotationally inlined functions to be offlined (in addition to extra overhead). For the following trivial class class A { public: void foo() {++i; } private: int i; }; I noticed that A* a = new A; int n = ..; while( n-- > 0) a->foo(); is about 300 times faster then (modify definition above to employ default singleton: class A : public basic_singleton<A>) A::pointer a; int n = ..; while( n-- > 0) a->foo(); (used g++ 3.3.3 on windows) ----------------- Author does admit that multithreading issues were not considered. IMO any singleton design that doesn't cover MT couldn't be accepted as generic. It's quite possible that it may need to be reworked completely to adopt MT issues. And piles of static variable used in implementation only confirm my suspicion. Interface ====== * I do not see a need for these basic_singleton and singleton_ex. Single template singleton with default template parameters would suffice * As I mention in design section interface with single "super policy" is unacceptable IMO * A::pointer interface is not convenient. I do not want to know about any "pointer". It should be either A::instance() or even better simply A; Most frequently I use this idiom (don't remember the name) class A_t { public: A_t& instance() {...} }; namespace { A_t& A = A_t::instance(); } Implementation ========== The submitted solution dropped on unaware user dependency on a <list>, <map>. <new>, <memory>, <cstring>, <cstdlib>, shared_ptr, aligned_storage and many other things. In my experiment simple include <singleton.hpp> leads to 1M of preprocessed code, while preprocessed size of trivial_singleton I am using in Boost.Test is ~6k. This all is a consequence of incorrect design and non-optimal implementation (too many interdependencies). I did not delve deep enough to comment in more details. Also I noticed that even default lifetime policy require partial specialization. Isn't clear why it should be this way. Tests ==== Tests are virtually absent. So there is nothing to comment here. Documentation =========== I guess it's not bad. But it's not my primary area of expertise. As you may figured by now my vote is NO. A would actually vote no even to include this into review queue, but did not paid enough attention at the time. Regards, Gennadiy. P.S. We really need go ahead with "mentor" idea. Also I would propose to enforce some "cool off" time (as 4 month since initial "query of interests point" is clearly not enough). May be it could enhance quality of submissions we invest time reviewing

4 5

Re: [boost] Re: char[] support in Boost.Range
by dan marsden 16 May '05

16 May '05

IMO the char[] as string default looks cool in the examples from boost for each and the string algorithms, but I cannot think of many practical examples of where I would have used it in my code. If I'm handing strings that I want to do something interesting with, I'll probably have read them into std::string as I usually cannot predict their lengths. Of course my experience may be atypical. Maintaining the uniformity of treatment of arrays would seem to me to be of more benefit in generic code. --- Eric Niebler <eric(a)boost-consulting.com> wrote: > > Pavol Droba wrote: > > On Sun, May 15, 2005 at 08:17:15PM -0400, David > Abrahams wrote: > > > >>"Thorsten Ottosen" <nesotto(a)cs.auc.dk> writes: > >> > >> > >>>| I'd like to leave it for the discussion. Right > now it seems, that > >>>| most of the people that entered discussion > prefer c-array view. > >>>| I would prefer c-string view, but I'm probably > biased by the fact > >>>| that I'm the author of StringAlgo library. > >>> > >>> I prefer the string view too. > >> > >>I just have one thing to say: vector<bool>. > >> > > > > > > Pardon me, but somehow I cannot figure out the > point here. Can you please > > explain the me the connection to vector<bool> > > > > > vector<bool> creates all kinds of problems because > generic code can't > make assumptions about the behavior of vector<T>. > vector<bool> is widely > regarded as a Bad Move. Dave is saying that treating > char[] different > than, say, int[] is inviting the same sorts of > problems. It will make it > difficult to deal with T[] in generic code. > > I agree with Dave. > > -- > Eric Niebler > Boost Consulting > www.boost-consulting.com > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

[string_algo] vc7 help needed
by Pavol Droba 16 May '05

16 May '05

Hi, Is there anybody with an access to vc7, who can help me with solving out remainig compatibility issues in string_algo library? There is just one last outstanding issue: http://tinyurl.com/cvl8x I can probalby get to fixing it, but because I'm not 100% sure what is the problem, I can only try and see the result. Unfortunaletely, it take very long to discover an error. Thanks. Best regards, Pavol.

1 0

[graph] libbgl-viz.lib #line problems work around...
by Rene Rivera 16 May '05

16 May '05

The problems that come up with some compilers not handling the #line directive: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/9jwue Can be worked around by not having the #line directives generated. All that's needed is adding the "-L" switch to have flex omit them. -- -- 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

1 0

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 16 May '05

16 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 13 May 2005 15:51 > To: boost(a)lists.boost.org > Subject: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > Try putting your function inside the namespace D2 I did. I also tried putting it in the global namespace. Same error. > Robert Ramey > > Marcin Tustin wrote: > > I'm trying to use the serialization and archive libraries, and I'm > > having a bit of trouble getting non-intrusive serializaton > to work; I > > keep getting the error > > "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: > > 'serialize' : is not a member of 'D2::Message'". My guess > is that for > > some reason the "long int" hack isn't working properly. I have > > serialize methods in the boost::seralization namespace like this: > > > > namespace boost { > > namespace serialization { > > template<class Archive > > > static void serialize(Archive & ar, const > D2::Message& g, const > > unsigned int version) > > { > > //... > > } > > > > } }; > > > > Which are textually before any use of the library, as far as I can > > tell. > > > > Any help would be much appreciated. > > > > Marcin Tustin > > IT Innovation Centre > > 2 Venture Road > > Chilworth Science Park > > Southampton, SO16 7NP, UK > > > > tel: +44 23 8076 0834 > > fax: +44 23 8076 0833 > > > > mailto:mt@it-innovation.soton.ac.uk > > http://www.it-innovation.soton.ac.uk > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > >

2 1

[Test Documentation] small error in HTML...
by Kevin Wheatley 16 May '05

16 May '05

libs/test/doc/usage/msvc_net.html contains a link to: post_build_event.JPG but the real file is with a lowercase extension at least it is on the main boost site, plus the www.boost-consulting.com/boost/ CVS 'reflector'. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

2 1

Re: [boost] Visual Studio 2005 Beta 2 + Multi Index
by JOAQUIN LOPEZ MU?Z 16 May '05

16 May '05

----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Domingo, Abril 24, 2005 2:07 pm Asunto: Re: [boost] Visual Studio 2005 Beta 2 + Multi Index > > > ----- Mensaje original ----- > De: Gordon Smith <schmoo2k(a)hotmail.com> > Fecha: Viernes, Abril 22, 2005 5:43 pm > Asunto: [boost] Visual Studio 2005 Beta 2 + Multi Index > > > The following stdafx.h for a vanilla console app kills the beta > 2 > > compiler > > (I think it creates a corrupt PCH file): > > > > #pragma once > > > > #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from > > Windows > > headers > > #include <windows.h> > > #include <tchar.h> > > > > // BOOST --- > > #include <boost/multi_index/sequenced_index.hpp> > > #include <boost/multi_index/ordered_index.hpp> > > > > Hi Gordon, excuse my late answering, somehow I just didn't see > your post amidst the current flow of messages. > > Did this work for MSVC 8.0 beta 1? I'm afraid I cannot help > much here except suggest that you try to report this to > the MSVC dev team: > > http://lab.msdn.microsoft.com/productfeedback/ > > Also, please try deleting all intermediate files before > doing a fresh compile --this is sometimes helpful specially > in regard to PCHs. If you make any progress or need some > help please keep me informed. > > Also, I forgot to mention: did you play with the /Zm option? http://msdn2.microsoft.com/library/bdscwf1c(en-us,vs.80).aspx Please keep me informed. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[string_algo] patch for bcc32
by Russell Hind 16 May '05

16 May '05

This goes a small way to getting string_algo to work with bcc32. The current errors I'm getting are in detail/find_format.hpp. If anyone can suggest a solution, I'd be happy to try it out. Thanks Russell regex_test.cpp: Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/algorithm/string/detail/find_format.hpp 133: 'operator!' not implemented in type 'find_format_store<const char *,regex_formatF<string>,string>' for arguments of the same type in function string find_format_copy_impl2<string,find_regexF<regex>,regex_formatF<string>,regex_search_result<const char *>,string>(const string &,find_regexF<regex>,regex_formatF<string>,const regex_search_result<const char *> &,const string &) Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/algorithm/string/detail/find_format.hpp 133: 'operator!' not implemented in type 'find_format_store<const char *,empty_formatF<char>,empty_container<char> >' for arguments of the same type in function string find_format_copy_impl2<string,find_regexF<regex>,empty_formatF<char>,regex_search_result<const char *>,empty_container<char> >(const string &,find_regexF<regex>,empty_formatF<char>,const regex_search_result<const char *> &,const empty_container<char> &) Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/algorithm/string/detail/find_format.hpp 72: 'operator!' not implemented in type 'find_format_store<const char *,regex_formatF<string>,string>' for arguments of the same type in function back_insert_iterator<string> find_format_copy_impl2<back_insert_iterator<string>,string,find_regexF<regex>,regex_formatF<string>,regex_search_result<const char *>,string>(back_insert_iterator<string>,const string &,find_regexF<regex>,regex_formatF<string>,const regex_search_result<const char *> &,const string &) Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/algorithm/string/detail/find_format.hpp 72: 'operator!' not implemented in type 'find_format_store<const char *,empty_formatF<char>,empty_container<char> >' for arguments of the same type in function back_insert_iterator<string> find_format_copy_impl2<back_insert_iterator<string>,string,find_regexF<regex>,empty_formatF<char>,regex_search_result<const char *>,empty_container<char> >(back_insert_iterator<string>,const string &,find_regexF<regex>,empty_formatF<char>,const regex_search_result<const char *> &,const empty_container<char> &) Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/algorithm/string/detail/find_format.hpp 193: 'operator!' not implemented in type 'find_format_store<char *,regex_formatF<string>,string>' for arguments of the same type in function void find_format_impl2<string,find_regexF<regex>,regex_formatF<string>,regex_search_result<char *>,string>(string &,find_regexF<regex>,regex_formatF<string>,const regex_search_result<char *> &,const string &) Error E2228 c:\Users\russell\Projects\boost-cvs\boost\boost/algorithm/string/detail/find_format.hpp 193: Too many error or warning messages in function void find_format_impl2<string,find_regexF<regex>,regex_formatF<string>,regex_search_result<char *>,string>(string &,find_regexF<regex>,regex_formatF<string>,const regex_search_result<char *> &,const string &) Index: boost/algorithm/string/config.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/config.hpp,v retrieving revision 1.4 diff -u -r1.4 config.hpp --- boost/algorithm/string/config.hpp 16 Jul 2004 13:57:40 -0000 1.4 +++ boost/algorithm/string/config.hpp 10 May 2005 13:08:30 -0000 @@ -17,11 +17,7 @@ # error "macro already defined!" #endif -#ifdef __BORLANDC__ -#define BOOST_STRING_TYPENAME -#else #define BOOST_STRING_TYPENAME BOOST_DEDUCED_TYPENAME -#endif // Metrowerks workaround #if BOOST_WORKAROUND(__MWERKS__, <= 0x3003) // 8.x Index: boost/algorithm/string/formatter.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/formatter.hpp,v retrieving revision 1.5 diff -u -r1.5 formatter.hpp --- boost/algorithm/string/formatter.hpp 12 Apr 2005 16:50:41 -0000 1.5 +++ boost/algorithm/string/formatter.hpp 10 May 2005 13:06:23 -0000 @@ -23,7 +23,7 @@ for a specific Formatter. An example of such a cooperation is regex_finder and regex_formatter. - Formatters are used as pluggable components for replace facilities. + Formatters are used as pluggable components for replace facilities. This header contains generator functions for the Formatters provided in this library. */ @@ -64,15 +64,19 @@ //! Empty formatter /*! Construct the \c empty_formatter. Empty formatter always returns an empty - sequence. + sequence. \param Input container used to select a correct value_type for the resulting empty_container<>. \return An instance of the \c empty_formatter object. */ template<typename RangeT> - inline detail::empty_formatF< + inline detail::empty_formatF< +// #ifdef __BORLANDC__ +// typename range_value<RangeT>::type> +// #else BOOST_STRING_TYPENAME range_value<RangeT>::type> +// #endif empty_formatter(const RangeT&) { return detail::empty_formatF< Index: boost/algorithm/string/sequence_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/algorithm/string/sequence_traits.hpp,v retrieving revision 1.7 diff -u -r1.7 sequence_traits.hpp --- boost/algorithm/string/sequence_traits.hpp 15 Jul 2004 21:48:25 -0000 1.7 +++ boost/algorithm/string/sequence_traits.hpp 10 May 2005 12:56:13 -0000 @@ -24,7 +24,7 @@ Due to a language restriction, it is not currently possible to define specializations for stl containers without including the corresponding header. To decrease the overhead - needed by this inclusion, user can selectively include a specialization + needed by this inclusion, user can selectively include a specialization header for a specific container. They are located in boost/algorithm/string/stl directory. Alternatively she can include boost/algorithm/string/std_collection_traits.hpp header which contains specializations for all stl containers. @@ -39,7 +39,7 @@ //! Native replace tester /*! - Declare an override of this tester function with return + Declare an override of this tester function with return type boost::string_algo::yes_type for a sequence with this property. \return yes_type if the container has basic_string like native replace @@ -49,31 +49,31 @@ //! Stable iterators tester /*! - Declare an override of this tester function with return + Declare an override of this tester function with return type boost::string_algo::yes_type for a sequence with this property. \return yes_type if the sequence's insert/replace/erase methods do not invalidate existing iterators. */ - no_type has_stable_iterators_tester(...); + no_type has_stable_iterators_tester(...); //! const time insert tester /*! - Declare an override of this tester function with return + Declare an override of this tester function with return type boost::string_algo::yes_type for a sequence with this property. \return yes_type if the sequence's insert method is working in constant time */ - no_type has_const_time_insert_tester(...); + no_type has_const_time_insert_tester(...); //! const time erase tester /*! - Declare an override of this tester function with return + Declare an override of this tester function with return type boost::string_algo::yes_type for a sequence with this property. \return yes_type if the sequence's erase method is working in constant time */ - no_type has_const_time_erase_tester(...); + no_type has_const_time_erase_tester(...); #endif //BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION @@ -89,7 +89,7 @@ private: static T* t; public: - BOOST_STATIC_CONSTANT(bool, value=( + BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_native_replace_tester(t))==sizeof(yes_type) ) ); #else // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION public: @@ -99,9 +99,9 @@ BOOST_STATIC_CONSTANT(bool, value=false); # endif // BOOST_WORKAROUND( __IBMCPP__, <= 600 ) #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION - - typedef mpl::bool_<value> type; + + typedef mpl::bool_<has_native_replace<T>::value> type; }; @@ -117,7 +117,7 @@ private: static T* t; public: - BOOST_STATIC_CONSTANT(bool, value=( + BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_stable_iterators_tester(t))==sizeof(yes_type) ) ); #else // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION public: @@ -128,13 +128,13 @@ # endif // BOOST_WORKAROUND( __IBMCPP__, <= 600 ) #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION - typedef mpl::bool_<value> type; + typedef mpl::bool_<has_stable_iterators<T>::value> type; }; //! Const time insert trait /*! - This trait specifies that the sequence's insert method has + This trait specifies that the sequence's insert method has constant time complexity. */ template< typename T > @@ -144,7 +144,7 @@ private: static T* t; public: - BOOST_STATIC_CONSTANT(bool, value=( + BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_const_time_insert_tester(t))==sizeof(yes_type) ) ); #else // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION public: @@ -155,13 +155,13 @@ # endif // BOOST_WORKAROUND( __IBMCPP__, <= 600 ) #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION - typedef mpl::bool_<value> type; + typedef mpl::bool_<has_const_time_insert<T>::value> type; }; //! Const time erase trait /*! - This trait specifies that the sequence's erase method has + This trait specifies that the sequence's erase method has constant time complexity. */ template< typename T > @@ -171,7 +171,7 @@ private: static T* t; public: - BOOST_STATIC_CONSTANT(bool, value=( + BOOST_STATIC_CONSTANT(bool, value=( sizeof(has_const_time_erase_tester(t))==sizeof(yes_type) ) ); #else // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION public: @@ -182,7 +182,7 @@ # endif // BOOST_WORKAROUND( __IBMCPP__, <= 600 ) #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION - typedef mpl::bool_<value> type; + typedef mpl::bool_<has_const_time_erase<T>::value> type; }; } // namespace algorithm

3 11

[Boost-bugs] [ boost-Patches-1202693 ] a simple patch about boost::format (for MSVC7.1)
by SourceForge.net 16 May '05

16 May '05

Patches item #1202693, was opened at 2005-05-16 16:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1202693&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lim Hwan Cheol (whitecrw) Assigned to: Nobody/Anonymous (nobody) Summary: a simple patch about boost::format (for MSVC7.1) Initial Comment: It seems to be a bug on MSVC7.1 compiler. that foolish compiler has some conflict on matching signature... 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' and 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' i think this is ultimately same signature. but, msvc71 doesn't.. for this, i used some #if tricks. :) attached patchfile contains my modifications. may the code be with you~ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1202693&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Python VC-8_0 errors
by Victor A. Wagner Jr. 16 May '05

16 May '05

I don't know why 7.1 says it's running (we don't get to see results of running things) but I know that if I funn args.py from my command line I get the same errors shown in results. I further note, that if I remove the '""" ........ """ from the .py file it claims it runs. I was under the impression that everything between """ and another """ was comment apparently something has changed in python 2.4, but I'm still baffled that the 7.1 says it's running. It appears there's something amiss in the testing framework Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

FOREACH / C++ "for" proposal
by Stefan Strasser 15 May '05

15 May '05

you might be interested in this document from the new c++0x mailing: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html for the naming discussion, proposed syntax is for(int i : vec) (personally I don't care if it's called BOOST_FOREACH or BOOST_FOR) I've questioned in the past if it is expected behaviour to do "hoisting". the proposal does. "4 Making a custom type work with the for loop" may also be interesting to make the BOOST_FOREACH extension mechanism similar. Regards, -- Stefan Strasser

13 46

Re: [boost] Re: [repost][interfaces] would the following work?
by JOAQUIN LOPEZ MU?Z 15 May '05

15 May '05

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Mayo 12, 2005 10:15 pm Asunto: [boost] Re: [repost][interfaces] would the following work? > JOAQUIN LOPEZ MU?Z wrote: > > [Sorry I didn't answer sooner; I'm reviewing a long manuscript] > > > Allow me to repost this, since given the current traffic in > > the list it could well have passed unnoticed. > > > > Is (the proposed) Boost.Interfaces lib able to handle the following > > scenario? > > > > > > template<typename T> > > interface IIterator > > { > > T& operator*()const; > > ... > > }; > > > > > > template<typename T> > > interface IContainer > > { > > IIterator<T> begin(); > > IIterator<T> end(); > > ... > > }; > > > It is not the issue of specifying an operator as part of the > interface> IIterator (this'll be taken care of in the future > according to the > > docs), but the fact that IContainer::begin is required to return an > > object implicitly convertible to IIterator<T>. Can Boost.Interfaces > > do that? > > This is one of the main motivating examples for introducing > operator overloading > and self-referential interfaces. Unfortunately, it's not done yet, > but it's the > first or second thing on my list. The implicit conversion from an > iterator of > the underlying container shouldn't be difficult. Iterators with > operatorsreturning proxies may be a problem. Another issue is that > IIterator<T> must > clone the underlying iterator; otherwise you will often end up > with pointers to > deallocated objects. > > I'm thinking of using the following syntax for polymorphic > container wrappers > (stealing from Andrei): > > sequence - sequence of anything > sequence::of<T> - sequence of T's > iterator - any iterator (more or less) > iterator::over<T> (or of<T>) - any iterator over T's Is this container wrapper stuff further elaborated somewhere I can take a look at? > > This allows sequence and iterator to be typedefs for template > specializationsinvolving allocator policies. > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > > > PS: Just for motivation, I' think this idiom could be taken > advantage> of in a possible implementation of a dynamic multi- > index container. > > Sounds great! > The rationale is, in a multi-index container where indices are added at run-time, some sort of dynamic polymorphism is called for when retrieveing and using the indices, much in the vein of the poly container wrappers. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

(BIL)Interfaces: Beta library
by tcmichals 15 May '05

15 May '05

Is there beta? When might it be available?

2 1

Re: (Named) Parameter Library
by Cromwell Enage 15 May '05

15 May '05

BTW, the include guards in <boost/parameter/macros.hpp> are all near the end of the file. I'll presume that's not where they should be? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

[string_algo] cw8.3 problem
by Pavol Droba 15 May '05

15 May '05

Hi, There is a reported problem with string_algo lib and cw8.3 http://tinyurl.com/bk9u2 I don't know what can be the problem. Can anybody with the access to this compiler have a look at it, please? Thank you. Pavol.

2 2

RE: ACT SPAM:[boost] [preprocessor] What syntax to present to the user
by Roman Yakovenko 15 May '05

15 May '05

> -----Original Message----- > From: loic.actarus.joly(a)wanadoo.fr > [mailto:loic.actarus.joly@wanadoo.fr] > Sent: Friday, May 13, 2005 1:22 PM > To: boost(a)lists.boost.org > Subject: ACT SPAM:[boost] [preprocessor] What syntax to > present to the user > > > Hello everybody, > > I'm trying to use the boost preprocessor library to allow the user to > define "rich" enums, for instance enums that cannot be > converted to int, > whose values can be displayed in human readable form on a stream... > > I think I have to use macro to ease the writing of such enums, and I ... There is a better approach. Try to search "smart enums" within boost mailing list archive Roman

1 0

failures-markup
by Pavol Droba 14 May '05

14 May '05

Hi Boosters, I'd like to ask for more caution when modifying explicit-failures-markup.xml file. Somebody has marked vc7 as unusable for string_algo lib, although the workaround is already on the way, and there is just few fixes to be done. I have unmarked this toolset few days ago, but it gets marked again. (Probably by mistake) It slows down my work since I don't have a direct access to this compiler so I must relay on the regression tests. Thanks. Pavol

2 1

[policy_ptr]source, sink policies proposal
by Larry Evans 14 May '05

14 May '05

Currently, policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… constains a conversion policy which determines whether or not to contain an implicit conversion to the raw pointer via the smart_ptr</*polcies typelist*/>::to<Referent> method: operator automatic_conversion_result(void) const; where: typedef typename conversion_policy::result_type automatic_conversion_result; However, since smart_ptr<...>::to<Referent> is derived as: class smart_ptr<P1, P2, P3, P4>::to : public detail::policy_ptr::conversion_policy_ couldn't the automatic conversion operator just be defined (in the case of allow_conversion) or not (in the case of disallow conversion) in the conversion policy itself? In addition, instead of allowing the raw pointer to escape from the "protection" of the smart_ptr via the storage policy's get_impl, why not delegate this decision to a "sink" policy, which decides how the pointee is exposed to outside use? IOW, rename the conversion policy to the sink policy which decides whether 'operator pointer_type()' or 'get_impl' are publicly exposed. This would allow for a "safer" smart pointer. Along the same lines, why not allow a "source" policy which decides the "inputs" (the CTOR args) to the smart pointer. Currently, for smart_ptr<...>::to<Referent>, the only "source", IIUC, is Referent*. (By source, I mean any CTOR arguments that don't include another smart pointer ). This would also allow for a "safer" smart pointer since the sole source could be something like David Abraham's auto_ptr_new: http://lists.boost.org/MailArchives/boost/msg42996.php

2 5

[Formal review] Singleton library
by Pavel Vozenilek 14 May '05

14 May '05

The formal review of Singleton library written by Jason Hise starts today, May 5th, and lasts 10 days. The library is available at http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… The singleton documentation can be browsed online at http://www.ezequal.com/chaos/docs/html/singleton/ Singleton is feature rich library: - ensuring single instance of a class and global access point to this instance - with policies specifying: - when the instance gets created (manually, immediatelly, when first used, ...) - how is the instance created (by new, malloc, in static memory, ...) - when the instance gets destroyed (never, by priority, after another singleton, ...) Parametrized singleton called Multiton is provided City::pointer p1("Chicago"); City::pointer p2("Brussels"); will create two different "singletons" of the same type. Another feature is ability to register resources (like shared pointer) who will get destroyed in controlled order, when the application exits. Not yet implemented features are: - MT safety - self-destroying singleton with timeout - bjam compatible tests The library is known to work with several newer compilers, VC7.1 among them. Help with other compilers is welcomed. When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. /Pavel

18 58

[program_options] Fix for 64 bit platforms
by Markus Schöpflin 14 May '05

14 May '05

Hello, attached patch has just been committed to program_options/src/cmdline.cpp. It fixes the test failures observed on Tru64 for the cmdline_test test and probably applies to all 64 bit platforms. As a side note, there are many other incorrect uses of unsigned in this file which also should replaced by the correct size_type, but currently these uses don't cause a test failure. Markus Index: cmdline.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/src/cmdline.cpp,v retrieving revision 1.18 diff -u -r1.18 cmdline.cpp --- cmdline.cpp 6 May 2005 07:48:45 -0000 1.18 +++ cmdline.cpp 13 May 2005 11:21:38 -0000 @@ -351,7 +351,7 @@ { string name, adjacent; - unsigned p = tok.find('='); + string::size_type p = tok.find('='); if (p != tok.npos) { name = tok.substr(2, p-2);

2 1

[website] New design is in CVS.
by Rene Rivera 14 May '05

14 May '05

The new design is now in CVS! But before people start saying.. "We don't like it! Why dis you put it in?" ... It was decided that having something now was better than having to wait for another release and have no progress shown on the website. Hence expect the design to continue to evolve after the release. Yell if you do an update, and find any problems. One WARNING, if you update either of the two new pages, index.htm and more/version_history.html, please process them with: tidy --tidy-mark no -i -wrap 78 -m -asxhtml --doctype strict [file] So as to ensure no errors creep in, and to make the formatting consistent. I'm trying to find a place to an instruction to that effect, but I can't readily see a place for it. Anyone have a suggestion where I should document running of tidy? -- -- 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

4 5

[Boost-bugs] [ boost-Bugs-1201779 ] compiler error on Mac implementation of threads
by SourceForge.net 14 May '05

14 May '05

Bugs item #1201779, was opened at 2005-05-13 21:36 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=1201779&group_… Category: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: compiler error on Mac implementation of threads Initial Comment: e-mail: myoula(a)videotron.ca With CW 9.4, Carbon (no Mach-O), and BOOST_HAS_MPTASKS defined I got: Error : illegal use of incomplete struct/union/class 'boost:: function<long, long>' safe.cpp line 50 boost::function<OSStatus, Duration> oWaitOnSemaphore; The error statement is marqued below by --> OSStatus safe_wait_on_semaphore(MPSemaphoreID pSemaphoreID, Duration lDuration) { -->boost::function<OSStatus, Duration> oWaitOnSemaphore; oWaitOnSemaphore = bind(MPWaitOnSemaphore, pSemaphoreID, _1); return(safe_wait(oWaitOnSemaphore, lDuration)); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1201779&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[range] vc support update
by Jonathan Turkanis 13 May '05

13 May '05

[My email to Thorsten bounced, so I'm posting it here] Thorsten, I finally got around to Boost.Range today. Sorry for the long delay. I've been able to get all the regression tests to pass on VC6, and all the tests to compile on VC7.0. I can't run the tests on the latter platform because of errors in Boost.Test. There are two points which deserve mention: 1. Array support only works for arrays of fundamental types. This should be mentioned in the docs, since it's not apparent from the regression test results. 2. With VC6, the function template arguments to range_end<>::fun() and range_size_<>::fun() were not deduced properly, leading to compiler errors. Since explicitly specifying the arguments caused internal errors, I used a trick from iostreams, and put the static function fun() in a nested class template whose template argument can be explicitly specified without problem; e.g.: template<> struct range_end<std_container_> { template< typename C > struct inner { static BOOST_RANGE_DEDUCED_TYPENAME range_result_iterator<C>::type fun( C& c ) { return c.end(); }; }; }; .... template< typename C > inline BOOST_DEDUCED_TYPENAME range_result_iterator<C>::type end( C& c ) { return range_detail::range_end<range_detail::range<C>::type>:: inner<C>::fun( c ); } This workaround is applied only for VC6. My question is: does this interfere with the extension protocol? If so, I think I can fix it, but only by adding another level of indirection. If you approve, I'll commit these changes. I haven't started working on Borland or GCC 2.9x yet. Jonathan P.S. I ended up not using the collection_traits headers -- the new dispatch mechanism made that unnecessary.

2 5

[1.33] README: Lots of files with no license/copyright
by John Maddock 13 May '05

13 May '05

There are currently quite a few source files showing up with no recognised license or copyright holder information: boost/graph/simple_point.hpp boost/wave/util/flex_string.hpp libs/date_time/example/local_time/local_date_time.cpp libs/date_time/example/local_time/seconds_since_epoch.cpp libs/graph/src/graphviz_digraph_parser.hpp libs/graph/src/graphviz_graph_parser.hpp libs/mpl/book/chapter1/binary.hpp libs/mpl/example/fsm/player2.cpp libs/ptr_container/test/algo_test_data.hpp libs/ptr_container/test/cast.cpp libs/ptr_container/test/concept_check_data.hpp libs/ptr_container/test/convert.cpp libs/ptr_container/test/indirect_vector.cpp libs/ptr_container/test/map_value_iterator.cpp libs/ptr_container/test/null_object.cpp libs/ptr_container/test/ptr_unordered_map.cpp libs/ptr_container/test/ptr_unordered_set.cpp libs/ptr_container/test/sequence_point.cpp libs/ptr_container/test/stack_example.cpp libs/ptr_container/test/tut5.cpp libs/ptr_container/test/vector_size.cpp libs/ptr_container/test/xml_tree_test.cpp libs/python/test/cltree.cpp libs/python/test/tuple.cpp libs/range/test/compat1.cpp libs/regex/performance/time_dynamic_xpressive.cpp libs/test/test/boost_check_equal_str.cpp libs/test/test/config_file_iterator_test.cpp libs/test/test/config_file_test.cpp tools/build/jam_src/filesys.c tools/build/jam_src/hcache.h tools/build/jam_src/subst.c tools/build/v2/test/boostbook/a.hpp tools/build/v2/test/dependency-test/src1/z.h tools/build/v2/test/unused/b.cpp And one file has both, but no date on the copyright: boost/ptr_container/detail/default_deleter.hpp Fixes would be much appreciated, before the release! Thanks, John.

11 26

Re: [ptr_container] memory corruption in ptr_set test
by Caleb Epstein 13 May '05

13 May '05

On 5/12/05, Thorsten Ottosen <nesotto(a)cs.aau.dk> wrote: > I can't easily deduce what the error should be from that file. Unfortunately I > don't have any of the failing compilers. > > Could the problem be related to dynamic cast and not enabling RTTI in the > compiler? No, thats definitely not it. Gcc enables RTTI by default. It looks to me like this call is the problem (for the instantiation of ptr_set_test< ptr_set<Base>, Base, Derived_class >): associative_test_data.hpp:108 i = c.find( *t ); According to valgrind, the memory location pointed to by t was previously deleted. Indeed, I added some debugging output to the Base class ctor and dtor methods, and this is what is happening: Running 1 test case... Base::Base @ 0x1bb45770 Derived_class @ 0x1bb45770 Base::Base @ 0x1bb45c58 Derived_class @ 0x1bb45c58 Base::Base @ 0x1bb46140 Derived_class @ 0x1bb46140 Base::Base @ 0x1bb46628 Derived_class @ 0x1bb46628 Base::~Base @ 0x1bb45c58 Base::~Base @ 0x1bb46140 Base::~Base @ 0x1bb46628 Base::~Base @ 0x1bb45770 Base::Base @ 0x1bb47d90 Derived_class @ 0x1bb47d90 Base::Base @ 0x1bb48798 Derived_class @ 0x1bb48798 Base::Base @ 0x1bb48c80 Derived_class @ 0x1bb48c80 ==15713== Invalid read of size 4 [...] ==15713== Address 0x1BB45770 is 0 bytes inside a block of size 24 free'd ==15713== at 0x1B904CA8: operator delete(void*) (vg_replace_malloc.c:155) ==15713== by 0x8062A4E: Derived_class::~Derived_class() (result_iterator.hpp:59) ==15713== by 0x8063A43: void boost::checked_delete<Base const>(Base const*) (checked_delete.hpp:34) ==15713== by 0x8063A22: void boost::delete_clone<Base>(Base const*) (clone_allocator.hpp:32) ==15713== by 0x8063A0E: void boost::heap_clone_allocator::deallocate_clone<Base>(Base const*) (clone_allocator.hpp:50) ==15713== by 0x80639FA: boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::set_config<Base, std::set<void*, boost::void_ptr_indirect_fun<std::less<Base>, Base, Base>, std::allocator<void*> > >, boost::heap_clone_allocator>::null_clone_allocator<false>::deallocate_clone(Base const*) (reversible_ptr_container.hpp:112) The address 0x1BB45770 corresponds to the first Base object, which comes from "t = new T" on line 56 of associative_test_data.hpp. This operation seems to be causing it to be deleted: associative_test_data.hpp:66 c3.clear(); > Running 1 test case... > unknown location(0): fatal error in "test_set": std::bad_typeid: Access > violation - no RTTI data! > > ^^^^^^^^^^ > > or is the compiler trying to say that it has seen a null pointer > ("location(0)") ? I assume it is due to the runtime zeroing out memory after it is freed, so the vtable of this object is overwritten. -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 13 May '05

13 May '05

I'm trying to use the serialization and archive libraries, and I'm having a bit of trouble getting non-intrusive serializaton to work; I keep getting the error "c:\boost_1_32_0\boost\serialization\access.hpp(106): error C2039: 'serialize' : is not a member of 'D2::Message'". My guess is that for some reason the "long int" hack isn't working properly. I have serialize methods in the boost::seralization namespace like this: namespace boost { namespace serialization { template<class Archive > static void serialize(Archive & ar, const D2::Message& g, const unsigned int version) { //... } } }; Which are textually before any use of the library, as far as I can tell. Any help would be much appreciated. Marcin Tustin IT Innovation Centre 2 Venture Road Chilworth Science Park Southampton, SO16 7NP, UK tel: +44 23 8076 0834 fax: +44 23 8076 0833 mailto:mt@it-innovation.soton.ac.uk http://www.it-innovation.soton.ac.uk

2 1

[ublas] 1.33 regressions in test4 and test5
by John Maddock 13 May '05

13 May '05

I don't know who (if anyone?) is maintaining ublas at present, but test4 and test5 are failing *on every single compiler* at present. I've partly traced the problem: an exception is being thrown in banded.hpp line 192, in : boost::numeric::ublas::banded_matrix<double,boost::numeric::ublas::basic_row_major<unsigned int,int>,boost::numeric::ublas::unbounded_array<double,std::allocator<double> > >::operator()(unsigned int i=0x00000000, unsigned int j=0x00000001) Line 192 + 0x34 C++ The cause is that the member data member _upper has been initialised to zero, which means any attempt here to access members of the matrix results in an exception being thrown! At present I'm stumped, I haven't been able to figure out what the code is supposed to do well enough to even begin to suggest a fix, so I'm just hoping this will ring a bell with someone, who'll know what to do :-) Regards, John.

2 2

[cvs] agurtovoy's lock
by Cromwell Enage 13 May '05

13 May '05

I keep running into it while attempting to get the latest and greatest version of Boost.Parameter; guess I'll wait until tomorrow. Cromwell D. Enage Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html

2 1

Critique of Boost.Threads
by Beman Dawes 12 May '05

12 May '05

With Kevlin Henney's permission, the following is a repost of a message he recently posted on the C++ committee's library reflector. It gives his views on Boost.Threads in the context of possible standardization. --Beman ------- In considering a threading library for C++ based on a fairly standard set of primitives, there are essentially two parts to such a library and it is worth considering these separately: the actual threading part, ie the part of the library concerned with the creation, execution and management of separate threads of execution; the synchronisation part, ie the part of the library concerned with locking. The two parts are obviously related in terms of execution, but there is no necessary relationship between them in terms of interface dependencies. These two parts are also in addition to the necessary guarantees of a reasonable memory model and other primitives appropriate for lock-free programming, which are also under related but separate discussion. For the C++ standard library a reasonable goal for both the threading and the synchronisation parts would be to adopt a generic-programming style of design. Although Boost.Threads uses templates in expressing some of its capabilities, it is a relatively closed design wrt extension, and hence not what would normally be termed generic. However, Boost.Threads does offer a starting point, and with only a few considerations and changes it is relatively easy to evolve a more open and appropriate design from it. Considering first the question of the threading part, Boost.Threads is currently based on the idea that a thread is identified with an object that launches it. This notion is somewhat confused by the idea that on destruction the thread object is destroyed but the thread is not -- in other words the thread is not identified the thread object... except when it is. There needs to be a separation of concepts here, which I will come back to in a moment. Another appropriate separation is the distinction between initialisation and execution. These are significantly different concepts but they are conflated in the existing thread-launching interface: the constructor is responsible both for preparing the thread and launching it, which means that it is not possible for one piece of code to set up a thread and another to initiate it separately at its own discretion, eg thread pools. Separating the two roles into constructor and executor function clears up both the technical and the conceptual issue. The executor function can be reasonably expressed as an overloaded function-call operator: void task(); ... thread async_function; ... asynch_function(task); The separation also offers a simple and non-intrusive avenue for platform-specific extension of how a thread is to execute: configuration details such as scheduling policy, stack size, security attributes, etc, can be added as constructors without intruding on the signatures of any other function in the threading interface: size_t stack_size = ...; security_attributes security(...); thread async_function(stack_size, security); The default constructor would be the feature standardised, and an implementation would be free to add additional constructors as appropriate. So far, this leads to an interface that looks something like the following: class thread { public: thread(); template<typename nullary_function> void operator()(nullary_function); void join(); ... }; Given that the same configuration might be used to launch other threads, and given the identity confusion of a thread being an object except when it's not, we can consider the interface not to be the interface of a thread but to be the interface of a thread launcher, also generally known as an executor: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executor.htm l http://www.cse.buffalo.edu/~crahen/papers/Executor.Pattern.pdf A thread initiator can submit zero-argument functions and function objects to an executor for execution: threader run; ... run(first_task); run(second_task); A standard library would offer a standardised threader type, but as a concept an executor could be implemented in a variety of ways that still conform to the same basic launching interface, ie the function-call operator. As a pleasing side effect, the potential confusion over the name "thread" is also removed: entities are named after their roles. Given that a threader can be used to launch multiple threads, there is the obvious question of how to join with each separately run thread. Instead of returning void, the threader returns an object whose primary purpose is to represent the ability to join with the completion of a separately executing thread of control: class threader { public: threader(); template<typename nullary_function> joiner operator()(nullary_function); ... }; The role played by the joiner in this fragment is that of an asynchronous completion token, a common pattern for synchronising with and controlling asynchronous tasks: http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf Via the joiner the initiator can poll or wait for the completion of the running thread, and control it in other ways -- eg request cancellation of the task (should we chose to attempt standardising in some form this often contentious and challenging capability). The joiner would be a copyable, assignable and default constructible handle, and as its principal action the act of joining can be expressed as a function-call: joiner wait = run(first_task); ... wait(); If there are no joiners for a given thread, that thread is detached, a role currently played in Boost.Threads by the thread destructor: run(second_task); // runs detached because return value ignored The final piece in this sketched refinement is the recognition that common across many C threading APIs is the ability to return a result from the function executed asynchronously (void * in Pthreads and DWORD in Win32). It seems to have become habit to discard this value in more OO interfaces, giving a result of void. For many threaded tasks this makes sense, but where a thread is working towards a result then the idea that an asynchronously executed function can return a value for later collection should not be discarded. With a void-returning interface the programmer is forced to set up an arrangement for the threaded task to communicate a value to the party that wants the one-time result. This is tedious for such a simple case, and can be readily catered for by making the joiner a proper future variable that proxies for the result: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Future.html http://www.laputan.org/pub/sag/act-obj.pdf http://kasparov.skife.org/blog/src/futures.html This leads to a threader interface like the following: class threader { public: threader(); template<typename nullary_function> joiner<result_of<nullary_function>::type> operator()(nullary_function); ... }; For the common default configured threader, a wrapper function, thread (as verb rather than noun), can be provided: template<typename nullary_function> joiner<result_of<nullary_function>::type> thread(nullary_function); And usage as follows: void void_task(); int int_task(); ... joiner<void> wait_for_completion = thread(void_task); joiner<int> wait_for_value = thread(int_task); ... int result = wait_for_value(); wait_for_completion(); The benefit of programming with futures is that for a certain class of code that would use end-of-thread synchronisation to pick up results, programmers are not presented with unnecessarily low-level synchronisation APIs. The function-based model is applied consistently. The sequence of steps, and the design considerations involved, to get from Boost.Threads to this design is hopefully clear and can be seen to be grounded in a great deal of existing practice, plus the benefit of a more native C++ appearance. Now, in terms of synchronisation the Boost.Threads library offers a number of primitives, such as mutexes, but unfortunately couples them to a relatively closed programming model. The synchronisation primitives provided do not lead to a general model for locking and force the user into using resource acquisition objects when this is not always the best solution. Given that C++ should aim to be the language and API of choice for systems-level work, the restriction of a mandatory scoped-locking interface does not seem appropriate. A more orthogonal approach based on the capabilities found in common across C++ synchronisation libraries, Boost.Threads included, would be a good starting point: lockability and locking strategy are kept separate. Taking a more generic approach, this means considering a related set of lock categories, eg Lockable and TryLockable. Something like Lockable would (syntactically) be little more than a.lock() and a.unlock(), and something like TryLockable would extend with a.try_lock(). Boost.Threads has some of this but restricts the interface of the lockable types themselves. With respect to these categories both primitives (eg mutex) and higher-level types (other externally locked objects) can be implemented. There is no dependency on the locking strategies that can be used against lockable objects -- scope bound, transaction linked, smart-pointer based, etc. The library would be expected to provide at least scope lockers to simplify the tedious and error-prone business of ensuring that scope-related critical regions are exception safe, but programmers would be free to define additional ones based on specific needs. There is also no requirement to pollute the nested scope of a lockable class with special typedefs. The Boost.Threads synchronisation library does not appear to satisfy the goal of openness and genericity. This is in part based on its well intended but mistaken belief that preventing programmers from using locks manually is the key to safe code: preventing users from using multiple threads and locks is the only way to do this. It is easy but annoying to work around the restriction (eg dynamically allocate the locker objects and control the lifetime on the heap instead of automatically wrt scope), but it should not be something that a programmer should have to work around. The Boost.Threads documentation itself admits that its restricted approach is extreme, but a more open and proven -- and less extreme -- approach is probably a better fit for standardisation. Therefore, the design we need to aim for is one that recognises that any use of explicit threading or any form of synchronisation is the programmer's responsibility. It should make common tasks easier and less error prone than they might otherwise be -- eg the provision of scope lockers -- but it should also allow the programmer the freedom to implement locking strategies as they see fit rather than force them to work around the API or seek another. I've only sketched it out, but hopefully there is enough rationale there to see why, without some refinement, Boost.Threads is not quite the right interface and execution model to standardise, but also how few hops it takes to build from Boost.Threads to an alternative API model that meets a reasonable and reasoned set of design objectives. Kevlin --

3 2

[repost][interfaces] would the following work?
by JOAQUIN LOPEZ MU?Z 12 May '05

12 May '05

Allow me to repost this, since given the current traffic in the list it could well have passed unnoticed. Is (the proposed) Boost.Interfaces lib able to handle the following scenario? template<typename T> interface IIterator { T& operator*()const; ... }; template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... }; It is not the issue of specifying an operator as part of the interface IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Just for motivation, I' think this idiom could be taken advantage of in a possible implementation of a dynamic multi-index container.

2 1

[filesystem] status() semantics?
by Beman Dawes 12 May '05

12 May '05

To nail down the semantics of status(), let's try a different approach. Some of the difficulty may be a matter of miscommunication, so perhaps actual code will add clarity. Perhaps Peter or others who have views on what the semantics of boost::filesystem::status() should be could change the code below to implement those semantics. Hopefully that will eliminate any confusion as to exactly meaning. --Beman --------- status_flag status_imp( const char * path, system_error_type * ec ) { struct stat path_stat; if ( ::stat( path, &path_stat ) != 0 ) { if ( ec != 0 ) *ec = errno; return ((errno == ENOENT) || (errno == ENOTDIR)) ? fs::not_found_flag : fs::error_flag; } system_error_type result(0); if ( S_ISDIR( path_stat.st_mode ) ) result |= fs::directory_flag; if ( S_ISREG( path_stat.st_mode ) ) result |= fs::file_flag; return result; }

2 2

[Boost-bugs] [ boost-Feature Requests-1200940 ] Support for embedded VC++ 4.0
by SourceForge.net 12 May '05

12 May '05

Feature Requests item #1200940, was opened at 2005-05-12 19:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200940&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: spinooch (spinooch) Assigned to: Peter Dimov (pdimov) Summary: Support for embedded VC++ 4.0 Initial Comment: Are there any plans to release a version of the smart pointer library that will compile under embedded VC++ 4.0? While trying to resolve the following compiler error: "shared_count.hpp(116) : error C2039: 'type_info' : is not a member of 'std'" I noticed that there are include files referenced in the hpp files that do not exist in the SDK provided with eVC++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200940&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Feature Requests-1200890 ] Support for embedded VC++ 4.0
by SourceForge.net 12 May '05

12 May '05

Feature Requests item #1200890, was opened at 2005-05-12 18:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200890&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: spinooch (spinooch) Assigned to: Peter Dimov (pdimov) Summary: Support for embedded VC++ 4.0 Initial Comment: Are there any plans to release a version of the smart pointer library that will compile under embedded VC++ 4.0? While trying to resolve the following compiler error: "shared_count.hpp(116) : error C2039: 'type_info' : is not a member of 'std'" I noticed that there are include files referenced in the hpp files that do not exist in the SDK provided with eVC++. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1200890&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Bug in boost 1.32: date_time/microsec_time_clock.hpp
by martin troxler 12 May '05

12 May '05

It is possible, that the following line boost::posix_time::ptime now = boost::posix_time::microsec_clock::local_time(); which invokes template<class time_type> class microsec_clock { static time_type local_time() { timeval tv; gettimeofday(&tv, 0); //gettimeofday does not support TZ adjust on Linux. return create_time(&tv); } static time_type create_time(timeval* tv) { time_t t = tv->tv_sec; boost::uint32_t fs = tv->tv_usec; ::std::time(&t); tm* curr = localtime(&t); .... returns a time with 1s off its correct value. The reason for this bug is the line with ::std::time(&t); that overwrites the second value just a few µs after the call to gettimofday. This new second value is used together with the fs value from gettimeofday. Example: tv from gettimofday: 12345s/999998 µs t from std::time: 12346s resulting time: 12346s/999998 µs !!!! Question: Why this call to std::time? I commented it out and it worked. Regards Martin

2 1

[iostreams] gcc-3.4.4 and amd64 patches
by Jürgen Hunold 12 May '05

12 May '05

Hi ! Please find a patch attached which tries to fix 2 issues: First, signed/unsigned mismatch in boost/iostreams/char_traits.hpp The fix is to change is_good(int) to is_good(std::wint_t) Second, boost/iostreams/filter/symmetric_filter_adapter.hpp contains two template implementations without corresponding definitions. gcc-3.4.x chokes on them. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

2 1

VS 2005 Beta 2 + 1.32
by Gordon Smith 12 May '05

12 May '05

Anyone build 1.32 (gold) with VS 2005 Beta 2? If so how? Thanks, Gordon.

2 3

[Boost-bugs] [ boost-Support Requests-1200700 ] Boost on opteron AMD
by SourceForge.net 12 May '05

12 May '05

Support Requests item #1200700, was opened at 2005-05-12 14:40 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=1200700&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: finte (finte) Assigned to: Nobody/Anonymous (nobody) Summary: Boost on opteron AMD Initial Comment: Hello, I need some help. How can I build boost on solaris 10 opteron amd as a 64-bit libraries? It's no problem to build bjam as 64-bit executables but with boost I failed. Has anybody any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1200700&group_… ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[ptr_container] memory usage causes problem with regression tests
by Martin Wille 12 May '05

12 May '05

Hello, for approximately a week now, I'm experiencing crashes when I run the regression tests. Victor told me he also noticed tests consuming unusual amounts of memory. I think I now found the culprit: the ptr_container test suite. This is the second time I notice the kernel run out of memory when once of the ptr_container tests is run. This is a problem for running the tests since the kernel then starts to kill processes. So this needs to get fixed ASAP. The ptr_set test output is: *** glibc detected *** free(): invalid pointer: 0x14347b4c *** Running 1 test case... unknown location(0): fatal error in "test_set": signal: SIGABRT (application abort requested) *** errors detected in test suite "Pointer Container Test Suite"; see standard output for details We need a way of portably specifying and enforcing time and memory limits for tests (it's not the first time I've been hit by tests running wild). We also need the authors of tests to make use of that feature, once we have it. I think displaying the time and memory used by a test in the regression results would be helpful (requires changes to Boost.Build, too, obviously). In this special case, it also would have been helpful if absolute times were printed in the output of Boost.Build, since all I have is the time-stamp from the error messages of the kernel but no way of correlating this time-stamp with the regression tests except for incidentally looking at the screen when the crashes happen. Regards, m

3 7

shared_ptr_test fails on rsi-sol g++ 4
by Peter Dimov 12 May '05

12 May '05

Any ideas why the three use_count() tests: { boost::shared_ptr<int> pi(new int); boost::shared_ptr<void> pv(pi); boost::shared_ptr<int> pi2 = boost::static_pointer_cast<int>(pv); BOOST_TEST(pi.get() == pi2.get()); BOOST_TEST(!(pi < pi2 || pi2 < pi)); BOOST_TEST(pi.use_count() == 3); BOOST_TEST(pv.use_count() == 3); BOOST_TEST(pi2.use_count() == 3); } fail as described here: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/ou… http://tinyurl.com/cq7qy ? -- Peter Dimov http://www.pdimov.com

1 2

[polymorphic_downcast]
by Thorsten Ottosen 12 May '05

12 May '05

Hi, is there any reason why we cannot say Base& get_ref(); Derived& boost::polymorphic_downcast<Derived&>( get_ref() ); ? It works with pointers, shouldn't we overload for references? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

2 3

[Regression Reports] Test case categorization
by Aleksey Gurtovoy 12 May '05

12 May '05

I'd like to draw library authors' attention to a recent generalization in the explicit markup scheme which allows one to control the grouping of a particular library's test cases in the Boost-wide regression reports, as demostrated here -- http://www.meta-comm.com/engineering/boost-regression/example/developer/lib… (http://tinyurl.com/bdd5u) The generalization is aimed at improving representation of library reports in at least two common situations: 1) "Duplicate" test cases: many libraries have two or more variations of the same test case for different configurations (DLL vs. static linking, char vs. wchar_t, etc.). 2) Test cases covering corner-case/optional/advanced functionality. In both of these cases, it's common to have an explicit markup (or actual failures) painting a group of test cases in a different color for one or more deficient toolsets -- see, for example, Boost.Thread page (http://tinyurl.com/8duf6) Test case categorization allows library authors to reduce the amount of visual clutter in the reports, giving them a more organized/structured look -- ultimately improving visitors' experience. Assigning a category to a test case or a group of test cases is just a matter of specifying the 'category' attribute to the corresponding '<test>' elements in "status/explicit-failures-markup.xml", e.g. <library name="my_library"> <test name="*_dll" category="DLL"/> </library> or <library name="iterator"> <test name="is_convertible_fail" category="Corner-case tests"> <mark-failure> <toolset name="borland"/> <toolset name="borland-5_6_4"/> <toolset name="msvc"/> <toolset name="vc7"/> <note refid="2"/> </mark-failure> ... As always, feedback is more than welcome. Enjoy, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Sandbox vault issues
by David Abrahams 12 May '05

12 May '05

Wow. Clicking typeof.zip gives me: Archive contents: Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Warning: unpack(): Type x: not enough input, need 1, have 0 in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: array_values(): The argument should be an array in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 103 Warning: fread(): Length parameter must be greater than 0. in /home/groups/b/bo/boost-sandbox/htdocs/vault/viewers/zip.php on line 104 Filename Size Date/Time boost/typeof/config.hppSD. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 4

[filesystem] status() if neither file nor directory?
by Beman Dawes 12 May '05

12 May '05

In http://www.esva.net/~beman/filesystem_operations_predicates.htm, the assumptions was that file system entities are either files or directories. But an operating system might support additional file system entities which can only be accessed via a specific API, and can't be accessed via fstreams or directory_iterators. For example, on some operating systems, sockets are file system entities and may be found during directory iterations, but can't be opened as either directories or fstreams. What to do? Possibilities: 1) Add an other_flag and a matching is_other() function. Change definition of exists() to status() & (directory_flag|file_flag|other_flag) 2) Try to identify specific other types like sockets, and define flags and predicate functions for each. Handle future needs by saying an implementation has to define suitable flags and predicate functions for any additional kinds of files. 3) Treat such entities as files. 4) Treat such entities as errors. 5) Treat such entities as not found. To me, (1) seems best. (2) is too open ended, and without a matching API to access the additional types, doesn't do much beyond (1). The others are not acceptable because they are misleading and don't match expectations. Comments? --Beman

4 22

[ptr_container] references & copyability etc (was [ptr_container] indirect_fun - do we still need it?)
by Pavel Chikulaev 11 May '05

11 May '05

"Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message news:d5tnql$2ll$1@sea.gmane.org... > what do you need the returned reference for? Just remembering rule: "Create your own classes that behave like int". isn't it? And IMO we should return reference to do these things: template<typename T> class ptr_cc_vector : public ptr_vector<T> //User's class to enable copyability { public: ptr_cc_vector(const ptr_cc_vector & that) : ptr_vector<T>(that.clone()) {} ptr_cc_vector & operator = (const ptr_cc_vector & that) { return *this = that.clone(); // :))) //Above is a bit better than //*this = that.clone(); //return *this; :)) } }; So, using ptr_container::clone is some kind of _very_ explicit copy constucting and assignment operator. Compare: a = b; a = ( b.clone() ); a(b); a( b.clone() ); and should behave like oridinal copy ctor and operator =. /////////////////////////// Let's start a new discussion about copyability :) I find ptr_cc_vector<T> very handy. Why not just enable copy ctor and assignment operator but in docs you will say explicitly that invoking copy ctor and assignment operator can be very very expensive in capital letters?? Or compromise: Add policy class By default ptr_containers are not copyconstructible, but it can be redefined if someone is willing to make ptr_containers copyconstructible template<typename T, ...., bool EnableCopyCtorAnd = DefaultBehavior> class ptr_vector; Someone, like you, will make DefaultBehavior for his ptr_containers Forbid. Someone, like me, will make DefaultBehavior for his ptr_containers Permit. IMO quite flexible, and everybody will be happy :) P.S. What's about clone_allocators - are they going to be not stateless or not? -- Pavel Chikulaev

2 1

Formal Review Request -- Interfaces
by Jonathan Turkanis 11 May '05

11 May '05

Hi, I would like to propose the proposed Boost Interfaces library, which I introduced several months ago, for formal review. (Or maybe I should say: I'd like to nominate the candidate Boost Interfaces library.) See http://www.kangaroologic.com/interfaces/ for download and documentation. The version to be reviewed will include a number of changes from the above version; in particular, about half of the features described in "Future Directions" will be implemented. However, the above version is self-contained and suitable for review, so I would like to propose it now and work on integrating the changes while it is sitting in the review queue. Jonathan

8 13

[ptr_container] indirect_fun - do we still need it?
by Pavel Chikulaev 11 May '05

11 May '05

Thorsten, Now, when we got rid of ptr_iterators, we don't need indirect_fun, do we? At least as part of ptr_container library? P.S. About copyability: may be then provide some cloning mechanism like: ptr_vector<int> a; ptr_vector<int> b(a.clone()); b = a.clone(); Where ptr_vector<T>::clone doesn't create clone immeadiately, but returns some object that refers to this, and ptr_vector<T> has ctor and assignment operator taking that object. Thoughts? -- Pavel Chikulaev

3 7

Re: (Another) socket streams library
by Nathan Myers 11 May '05

11 May '05

I was directed to this thread after some work to make GNU libstdc++ expose POSIX pipe semantics at the istream::readsome() level, which probably will show up in release 4.0.1. (Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286 ) It started me thinking about how to make an iostream useful when attached to a non-blocking socket. Reading this thread, it seems to me you have stepped in the same trap as most other attempts. There are many, many libraries to make various sources and sinks, including sockets, look like iostreams, but without actually being iostreams. We don't seem to find ourselves using them. For nonblocking socket support to be widely useful, it must be possible to pass such a stream to a library that takes a regular istream& or ostream& argument. This has been characterized as impossible, because iostream semantics are not compatible with non-blocking I/O. While the latter is true, the former is not. The key to the paradox is the expression "out-of-band". The owner of the stream may know things about it, and its underlying socket, that the user of the istream or ostream does not, and can act accordingly. Most particularly, the owner may know that the amount of input or output to be done will not cause any system calls to return EWOULDBLOCK. The next question is, how do we know how much I/O we can do without blocking? It is common for select not to wake up a process for writing on a socket until there is more than (say) 4K of space in the output buffer. Therefore, any use of the socket that will not produce more than 4K of output is safe. An actual TCP "out-of-band" notification from the other end may help, indicating that the last written data have all arrived, proving that a full 64K of buffer space awaits. On input, we must ensure that our override of streambuf::underflow is satisfied by a short read, and that the user of the attached istream will be satisfied with what it actually finds, and won't loop trying to get more. These conditions seem awfully restrictive, but there remain a large class of problems for which they are not *too* restrictive. What remains is to identify and package up all the usable out-of-band notification mechanisms associated with sockets, and try to achieve some abstraction and perhaps even (who knows?) portability. Nathan Myers ncm(a)cantrip.org

5 15

parameters library and rvalue pitfall
by David Abrahams 11 May '05

11 May '05

I just added an index_result metafunction that was requested during the review, for getting the result of a named parameter lookup, possibly with a default or a lazy default. Whereas previously, you would write the following to implement your function with named parameters, template<class Params> void f_impl(const Params& p) { g( p[name] , p[value || boost::bind(&value_default) ] , p[index | 999 ] ); } now you have the option to write something like this: template<class Params> void f_impl(const Params& p) { typename boost::parameter::index_result< Params, struct name_>::type& n = p[name]; typename boost::parameter::index_result< Params, struct value_, double >::type const& v = p[value || boost::bind(&value_default) ]; typename boost::parameter::index_result< Params, struct index_, int >::type const& i = p[index | 999]; g(n,v,i); } The problem, which you may have noticed, is that in the latter case you may be creating dangling references to destroyed rvalues. In the case of the index parameter above, the rvalue 999 gets bound to a const reference that then *passes through* the operator[] and initializes i. Since p[index | 999] returns a const reference and not a value, i is bound directly to the original rvalue 999 which is destroyed at the end of the full expression. The question is, what should we do about this? It turns out to be surprisingly hard to write the declarations of these temporary variables so they work in all cases. For example, v had to be a const& because in one case index_result<...>::type turned out to be char const[4] and when the default is used, it's double with p[value || ...] returning a double rvalue (by value). Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 10

[test] and bcc32 errors
by Russell Hind 11 May '05

11 May '05

Running the regression tests on boost.test with bcc32 leads to many errors like this (and also in other libs regression tests) basic_cstring_test.cpp: Error E2093 c:\Users\russell\Projects\boost-cvs\boost\boost/test/predicate_result.hpp 51: 'operator!' not implemented in type 'tt_detail::equal_impl_frwd' for arguments of the same type in function predicate_result::predicate_result(const tt_detail::equal_impl_frwd &) Any ideas what is going on? Thanks Russell

2 8

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <428133DD.20505(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > Wouldn't someone wanting to do something "clever" like that fall back to > using a normal for() or while() loop? I thought for(i:vect){} is a > convenience function to save typing and make code clearer; can it do > something a while() loop cannot? I don't think it makes the code clearer, because it looks like a use of i rather than a declaration. I think it is very important for readability that names be declared explicitly. That is a general point. What you are proposing: for (i: vec) is especially misleading because it is inconsistent with: for (i = vec.begin(); i != vec.end(); ++i) I really don't think one should declare i and the other, not. What's wrong with: for (auto i: vec) ? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <d5qtbh$cpi$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > which example are you referring to? The one using my_range_adapter, in section 4 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html > chances are that <vector> will include <iterator> anyway. I'd rather not have to take chances with my code. -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] Re: Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 11 May '05

11 May '05

In-Reply-To: <00fb01c55599$e9fc23e0$6401a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that defining size( T[N] ) as N or N-1, depending on whether T > is a character type, will cause problems in generic code and preclude > the widespread use of the library. I agree. If we do support null-terminated character strings, can we support other kinds of terminators too? (Without undue loss of efficiency.) For example: int array[] = { 1, 2, 3, -1 }; int *pArray = array; for (int i, terminator_adaptor(pArray,-1)) cout << i; // Does not write -1. This can be useful if the size of the array is not visible to for(:). I use terminators fairly often, usually NULL for pointers, 0 or -1 for integral types, and "end" for enums. It's not something specific to characters. In fact, for me the need to enumerate character strings is rarer than for these other types. Usually strings are either wrapped in std::string or similar, or else passed to some other routine. By "Without undue loss of efficiency" I really mean without scanning the sequence an extra time to find the end. My impression is that BOOST_FOR_EACH had a fairly general termination mechanism which could cope with that. -- Dave Harris, Nottingham, UK.

1 0

[test] mingw (3.2.3) failure
by Gennadiy Rozental 11 May '05

11 May '05

Does anybody know what the deal here? Test output: mslater - test - basic_cstring_test / mingw Linker output [2005-05-10 22:57:32 UTC]: "g++" "-Wl,--enable-auto-image-base" -g -Wl,--allow-multiple-definition -mno-cygwin -o "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.exe" -L"C:/testing/boost/results/bin/boost/libs/test/build/libboost_unit_test_framework.lib/mingw/debug" "C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" "C:\testing\boost\results\bin\boost\libs\test\build\libboost_unit_test_framework.lib\mingw\debug\libboost_unit_test_framework.lib" C:\testing\boost\results\bin\boost\libs\test\test\basic_cstring_test.test\mingw\debug\basic_cstring_test.obj(.text$_Z19asignment_test_implIwEvPN5boost4typeIT_EE+0xef): In function `ZSt4setwi': c:/mingw/include/c++/3.2.3/iomanip: undefined reference to `std::char_traits<wchar_t>::compare(wchar_t const*, wchar_t const*, unsigned)' And a lot more like this. Why references to std::char_traits<wchar_t> symbols are undefined? Gennadiy

3 4

Re: [boost] Re: Formal Review: FOREACH macro
by Peter Dimov 11 May '05

11 May '05

Peter Dimov wrote: > Eric Niebler wrote: > >> Yes, but I was refering to native (C-style) strings, as in: >> BOOST_FOREACH(char ch, "hello world") > > This is a good opportunity to ask: what does this do? > > char const a[] = { 0, 1, 2 }; Or for extra fun, drop the 0. > BOOST_FOREACH( int x, a ) > { > std::cout << x << std::end; > }

6 20

Review Schedule (11-May-2005)
by Tom Brinkman 11 May '05

11 May '05

The singleton library review started on 5-May-2005. If you haven't done so already, download the library at http://tinyurl.com/6qvrd. You should submit a review by 15-May-2005. The Typeof Library review begins 20-May-2005. You can download this library at http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) Contact Tom Brinkman at reportbase(a)gmail.com for updates to this schedule. Review Queue as of May 11, 2005 1) Singleton (Current) 5-May-2005; Ends: 15-May-2005 2) Typeof Starts: 20-May-2005; Ends: 30-May-2005 3) Function Types Starts: 5-June-2005; Ends: 15-June-2005 4) Logging To be confirmed: 20-June-2005; Ends: 30-June-2005 5) Policy Pointer To be confirmed: 5-July-2005; Ends: 15-June-2005 Other Libraries (no particular order): 6) Fixed Strings 7) Intrusive 8) TR1 9) Fusion 10) Factory 11) Interfaces 1) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com peder.holt(a)gmail.com Review Manager: Andy Little andy(a)servocomm.freeserve.co.uk Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 4) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser hartmut.kaiser(a)gmail.com Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 5) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 6) Fixed Strings Author: Reece Dunn msclrhd(a)hotmail.com Review Manager: Beman Dawes bdawes(a)acm.org Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 7)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 8) TR1 9) Fusion 10) Factory Author: Federico Stella f.stella(a)flashnet.it 11) Interfaces Author: Jonathan Turkanis <technews(a)kangaroologic.com> Review Manager: Needed Available: http://www.kangaroologic.com/interfaces "Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the 'dot' operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. "Current applications of Boost.Interfaces include: * Non-intrusive dynamic polymorphism — interfaces can often be used in place of abstract base classes, and are sometimes much faster (see Performance). * Dynamic inheritance — allows function calls to be forwarded automatically to an object specified at runtime (see Delegation). * Smart Interface Pointers — smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References — like smart interface pointers, but the managed object is accessed using the "dot" operator."

1 0

Boost.Test: major update
by Gennadiy Rozental 11 May '05

11 May '05

Hi, I would like to take this moment to share with you finally the modifications Boost.Test went through during last couple month. Most of Boost.Test components undergo a major or significant change in both design and implementation. I've strived to keep an interface unchanged as much as possible. The primary goals for this update were: * Make a unit test framework better suited for different 'runners' * Make unit test framework simpler internally by eliminating test cases hierarchy * Make test tools more uniform * Make auto unit test framework as usable as possible Following are details of what updated/changed specifically in each area of Boost.Test: I. Execution Monitor The execution monitor design changes from inheritance to delegation. If previously one needed to inherit from the boost::execution monitor to do a monitored run of a function, now one need to employ an instance of the boost::execution_monitor: boost::execution_monitor em; // register translators for custom user exception em.register_exception_translator<ExceptionType>( my_translator ); em.execute( function_to_execute ); function_to_execute should be any zero arity function or function object. To implement the polymorphic function handling I employ my own class callback (see utilities section). I did not want to introduce a dependency on Boost.Function. But in a future I plan to switch to tr1::function. In addition following features implemented: * Debugger presence detected, in which case catching system errors (SEH) is disabled unless explicitly enabled. For now only works for msvc family * Automatic detection of memory leaks introduced. For now only works for msvc family Unit test framework turns this feature on by default. User could manage it by specifying runtime parameter (in a form of command line argument or environment variable). For example test --detect_memory_leak=<leak_allocation_number> set leak_allocation_number to integer number: 0 - to disable detection of memory leaks; 1 - to enable detection of memory leaks; N>1 - to enable detection of memory leaks and set a system breakpoint at the moment of Nth memory allocation. For more on how to find N and some issues with usage of this feature see documentation II Unit test framework (UTF) This component of Boost.Test undergo a most dramatic changes in both design and implementation. Here are main modifications: 1. UTF doesn't employ test cases hierarchy anymore. There is single class test_case that model one testing unit and class test_suite that model a collection of test units. Previously UTF employed compound test cases (for example parameterized test case) which went through it's components (simple subtests) during testing run time. Now compound test present itself as test case generator which produce a collection if test_case instances during test tree construction time. One consequence of this is that user doesn't need to keep track of compound test case parameters is it used be. test_case now employs a polymorphic callback to a actual test function. As a result of this one could supply any zero arity function as an argument of BOOST_TEST_CASE. SO no extra support needed to be able to create boost::function or boost::bind based tests cases. 2 .Introduced generic mechanism to traverse the test tree. Anyone willing to do so just need to implement test_tree_visitor interface and employ traverse_test_tree. This allows to implement any pre/post processing over test tree. 3. Introduced a notion of framework. The framework is responcible for: a) initializing and providing access to master test suite b) providing access to current test case c) running testing from given test tree node (simple or compound). By default it runs from root - master test suite. Supports both sequential and random order. d) One may register any test observer agent (implements test_observer interface) and framework notifies it of all test events e) providing access to any test case based to unique test unit id Using the framework one could implement different test runners. UTF library supplies one console runner (unit_test_main.cpp). But it's possible to do one winmain based or anything else. For example GUI program that build test tree and then run tests by request from any point in test tree. 4. Unit test log interface changed to single line (used to be begin/end macros). Unit test log formatter interface changed. How it much simpler and straightforward. Two supplied implementation are separated. 5. Notion of unit test result that was responcible for result collection and reporting eliminated. Instead introduced independent notions: results_collector and results_reporter. Results reporting formatter interface made public. Also results_reporter now allows to change an output stream. 6. Progress monitor functionality (which used to be activated in log level log_progress) now is an independent test observer and implemented by class progress_monitor. 7. Test case template interface changed. Now user doesn't need to explicitly register meta class. In addition couple more features implemented: * Added support for test case timing * UTF made __cdecl - safe * Result report include skipped tests * io saver facilities employed to guard against undesirable modification in output streams formatting * template test case automatically generate name that includes type name * --detect_memory_leak and --random cla added III Test Tools The two major changes in Test Tools are: * Test Tools interfaces to provide 3 version for each tool: CHECK- reports an error if assertion failed WARN - reports a warning if assertion failed REQUIRE - reports an error if assertion failed and aborts test case execution * Test Tools implementation completely reworked. All tools implemented now through single vararg function In addition following modifications made: * CHECK_COLLECTION interface changed: it now expect 4 arguments * BITWISE_EQUAL renamed to CHECK_BITWISE_EQUAL; old name still provided, but is deprecated * CHECK_COLLECTION interface changed to use PP_SEQ and as a result support arbitrary(actually maximum is fixed but configurable) number of predicate arguments * most of templates eliminated speeding up test modules compilation * floating-point precision set to include all significant digits (actually the formula may require some rework since it obviously doesn't do a good job sometimes) * BOOST_CHECK/WARN/REQUIRE_SMALL test tool added * old test tools names are *deprecated* IV Auto unit test framework Interesting discussion with Noel Llopis and several user requests lead to several additions to the auto_unit_test.hpp. Here is a short descriptions: * BOOST_AUTO_UNIT_TEST renamed to BOOST_AUTO_TEST_CASE. Old name still provided but deprecated * BOOST_AUTO_TEST_CASE_TEMPLATE provides an ability to write a self-registering test case template * BOOST_FIXTURE_TEST_CASE provides an ability to write a self-registering test case with fixture * BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES provides an ability to specify a number of expected failures in any self-registering test case * BOOST_AUTO_TEST_SUITE and BOOST_AUTO_TEST_SUITE_END provide an ability to structure test cases into self-registering test suites V Included components Implementation moved from source files (.cpp) under lib/test/src into implementation files (.ipp) under boost/test/impl to eliminate dependency of included/minimal components on lib/test/src directory. VI Utilities Basic utilities that may have value outside of Boost.Test now separated into utils subdirectory. If there is an interest to promote any of them onto public boost level I am ready to discuss it. Here is a short descriptions (some of them existed before, but most are new): 1) algorithm.hpp Implements several variations of STL algorithms including 4-arg mismatch 2) assign_op.hpp Hook for overloadable assignment 3) callback.hpp Implements a polymorphic function callback facility (similar to boost::function). 4) class_properties.hpp Simple facility that mimic notion of read-only read-write properties in C++ classes 5) custom_manip.hpp Simple helpers for creating custom output manipulators 6) fixed_mapping.hpp Fixed sized mapping (initialized in constructor ) with specified invalid value. 7) foreach.hpp This is an abridged version of BOOST_FOREACH. The only difference is portability. 8) named_params.hpp Facility for named function parameters support. Even though Dave A. did not see a value in my suggestion during Boost.Parameter review period. I couldn't justify for myself using that inconvenient interface (IMO) and absence of optional parameters. This facility implements an alternative solution with different set of tradeoffs and features. It used in several places in Boost.Test. 9) nullstream.hpp I should probably deprecate this one , but more-io was not accepted. 10) rtti.hpp Simple alternative to compiler RTTI. Provides an access to unique type id at runtime. I plan to extend this to implement type_descr similar to what is described in "C++ template metaprogramming". 11) trivial_singleton.hpp As the name suggest this simple singleton helper. 12) wrap_stringstream.hpp Wraps strstream and stringstream (depends with one is present) to provide the unified interface 13) basic_cstring/ class template basic_cstring wraps raw memory pointers and provide std_string like interface 14) iterator/input_iterator_facade.hpp Helps to build input iterators 15) iterator/token_iterator.hpp Yet another token iterator 16) iterator/istream_line_iterator.hpp Iterate over istream and produce lines 17) runtime/ This is long promised framework for parsing CLA handing environment variable and parsing config files. This is an alternative solution to what boost::program_options present. Unfortunately I did not have enough time to incorporate it completely into Boost.Test main components, so the detailed description will follow once this will happened. Sorry, for babbling for so long. Any comments are greatly appreciated. Regard, Gennadiy

3 5

[patch] Memory leak in the thread_specific_ptr implementation in Boost.Threads
by Jeremie Detrey 11 May '05

11 May '05

Hello, It seems to me that there is a possibly huge memory leak in the file boost/libs/thread/src/tss.cpp, as the thread specific data slot vector is allocated (line 120) but never freed. It causes a few bytes' memory leak for each thread, as it appears when using valgrind (see attached files: input program = example.cpp, valgrind output = example.valgrind). I propose here a simple patch to fix this. It works perfectly with my programs, and frankly I cannot see why it should not work. Thanks, Jeremie Detrey.

1 0

Boost.Python embedding/extending example
by Neb Naic 11 May '05

11 May '05

Hello, I have an application that I need to both embed and extend Python. The Python portion is actually an existing plotting utility that I�m trying to leverage in a legacy C++/OpenGL application. The Boost.Python tutorial has helped me successfully expose my C++ classes to Python. However, I�m having difficulty embedding the Python � accessing Python interfaces from C++. The tutorial examples seem to lean toward embedding Python statements rather than actually addressing interface issues (IMHO). Assuming the Python code to embed is in its own file (not actually embedding Python statements), does Boost.Python provide an encapsulated class or functional interface? Documentation/examples? Any help is greatly appreciated. Thanks, Niac __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

2 1

[interfaces] would the following work?
by Joaquín Mª López Muñoz 11 May '05

11 May '05

Is (the proposed) Boost.Interfaces lib able to handle the following scenario? template<typename T> interface IIterator { T& operator*()const; ... }; template<typename T> interface IContainer { IIterator<T> begin(); IIterator<T> end(); ... }; It is not the issue of specifying an operator as part of the interface IIterator (this'll be taken care of in the future according to the docs), but the fact that IContainer::begin is required to return an object implicitly convertible to IIterator<T>. Can Boost.Interfaces do that? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: Just for motivation, I' thinkthi s idiom could be taken advantage of in a possible implementation of a dynamic multi-index container.

1 0

Re: [mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Andy Little wrote: > > There may be an implementation of gcd<> that is > > more efficient even if it works solely on > > big_integral<> numbers. > > Surely it would make sense to specialise this for > big_integral. Yes. > > Or there may not, but for now, I shouldn't rule out > > anything that promises to make big_integral<> > > operations less expensive. > > But these operations will now be unneccessarily > expensive for small_int types. Then there should be a gcd specialization for them, too, right? One that doesn't require recursive apply2<> calls? > Your version of gcd looks is obviously optimised > for big_integral. Really? I haven't even taken advantage of anything that's specific to big_integral<>, but okay... ...if I ever get big_integral<> to work. > However my requirements on rational would be for a > large number of smallint types. I hope you will take > this into account in the design and favour the > implementation more towards small_int types as well. Okay. > OK maybe that would be quicker, and give better error > messages. But you will need a tag dispatch mechanism > anyway wont you?, to avoid a large number of > specialisations. Yes. Like I said, I'll do that. Cromwell D. Enage Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

1 0

[patch, boost.regex] Kill warning when compiling without exceptions
by larsbj＠gullik.net 11 May '05

11 May '05

This is the only warning I get when compiling the subset of boost that is included in LyX. Would be nice to see this in 1.33. This is with gcc 3.3.3. diff -ru --exclude=CVS boost/boost/regex/v4/basic_regex_parser.hpp lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp --- boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-09 10:35:34.000000000 +0200 +++ lyx-upboost/boost/boost/regex/v4/basic_regex_parser.hpp 2005-05-10 22:27:37.124642889 +0200 @@ -147,6 +147,8 @@ template <class charT, class traits> void basic_regex_parser<charT, traits>::fail(regex_constants::error_type error_code, std::ptrdiff_t position) { + // Avoid warnings when compilinging without exceptions. + (void)position; if(0 == this->m_pdata->m_status) // update the error code if not already set this->m_pdata->m_status = error_code; m_position = m_end; // don't bother parsing anything else -- Lgb

2 1

[mpl] Math sublibrary: new version.
by Cromwell Enage 11 May '05

11 May '05

--- Dan Perry wrote: > I need some sort of compile time float type that > supports multiplication and division. I found your > comments on the gmane.comp.lib.boost.devel newsgroup > via google but I can't access your mpl_math.zip > file. Could you send me your source? Thanks. The file has a new home. Go to <http://boost-sandbox.sourceforge.net/vault/>, look under the subdirectory "expaler", and download from there. Major issues: 1. The big_integral<> numeric "metatype" is still a compiler resource hog. If I could use list<> instead of vector<>, I may be able to make it more efficient. To do so, I would need to know how to iterate through two lists "concurrently" instead of one list at a time. Aleksey Gurtovoy, any pointers? 2. The most recently added numeric metafunctions, which are square_root<>, exponent<>, sine<>, cosine<>, arctangent<>, hypersine<>, and hypercosine<>, are either insufficiently tested or not tested at all. 3. The numeric_caster_rt facility probably needs a more appropriate name. It is untested with wrt boost::rational as the ResultType. It is also non-functional wrt complex_number<>, at least until I figure out how to use std::complex. 4. Documentation should be available in the next version. For now, the source code, examples, and test programs will have to suffice. Andy Little wrote: > Why not call this one mixed_number? Okay, your suggested name changes have been applied. Also, except for big_integral<>, the NumberSign parameter is now removed. Examples: rational<int_<11>,integral_c<long,16> > rational_c<long,-9,5> mixed_number<long_<2>,int_<54>,integral_c<int,100> > mixed_number_c<int,0,-2,5> The following expressions are currently illegal: rational<int_<1>,int_<0> > rational_c<long,9,-5> mixed_number<long_<3>,int_<-1>,integral_c<int,2> > mixed_number_c<int,0,6,5> I'm currently debating with myself about whether to make aux::rational2mixed_number<> part of the public interface; and if so, whether to rename it to something more legible; or if not, whether mixed_number<> and mixed_number_c<> should take default parameters. > IMO the rational Concept should hold independent of > the exact parameters. The types used for the > parameters are a trade off between using small_ints > and having a relatively quick compile with the > possibility of everflow, as against big_integers with > long compile (and posibly run) times. Actually only the relationship between the concept and the implementation models was dependent on the parameter "metatypes". But I know what you meant, so don't worry about it. > However in a large number of cases a rational has > known bounds, so an inbuilt int has ample range. Yeah. It's when you try things like the square_root<> example program (included in the zip file) that the inbuilt range becomes not enough. > I am wondering if the more lazy implementation > possible by moving away from integral constant > expansion might improve matters. OTOH perhaps it > will make matters worse. (I am no expert on 'lazy' > programming...but it must have some benefit?) I'll try to implement some lazy versions of both big_integral<> and the new numeric metafunctions in the next version. > It is merely one among several possible compile time > types that Might be useful as parameters. Other > possibilities are the aforementioned big_int and a > complex, should One not try to make the thing generic > as possible? I dont think anything is lost by it. > Even if the helper functions like gcd and abs are not > useful for this they may come in useful somewhere > else. I've reimplemented rational<> so that it accepts any numeric constants M and N for which modulus<M,N> is a valid expression. That should improve its genericity. Cromwell D. Enage __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 3

[serialization] gcc 3.4.3 / ld / serialization issue?
by Christoph Ludwig 10 May '05

10 May '05

Hi, this post belongs to the thread <url:http://lists.boost.org/MailArchives/boost/msg76063.php> but I don't have that thread in my local archive anymore. I face the same problem as Curtis Spencer did. Linking an application built with g++ 3.4.3 against boost_serialization-gcc-mt produces warnings from the linker: g++ -pthread -g -O2 -pthread -o testsuite-LaRed testsuite-LaRed.o ReductionTestdata.o testcase-Testdata.o testcase-Matrix.o testcase-GS.o testcase-LLL.o testcase-BKZ.o testcase-RSR.o -L/home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared_ntl.a /home/cludwig/Cxx/gcc3.4/LaRed-0.1-BUILD/src/.libs/liblared.a -lboost_unit_test_framework-gcc-mt -lboost_serialization-gcc-mt -lboost_filesystem-gcc-mt -L/home/cludwig/Cxx/gcc3.4/usr/lib/ -lntl /usr/lib/libgmp.a `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' referenced in section `.rodata' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o): defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of /home/cludwig/Cxx/gcc3.4/usr/lib//libboost_serialization-gcc-mt.a(basic_iarchive.o) (There are similar warnings from basic_text_iprimitive.o and xml_grammar.o. The compiler / Boost configuration are reported at the bottom of this post.) The linker generates an executable anyway and it _seems_ to work. However, I observe infrequent crashes of the application that I don't observe on a machine where I built Boost and the application (without any warnings) with gcc 3.4.2 / ld 2.14.90.0.5. Thus I suspect that the warning is there for a reason and points to the problem causing the crashes. Has anyone an idea what to do about this? I am not sure the problem is caused by the serialization library, but Googling araound I found that it is often exposed by boost_serialization-gcc-mt. There is already a gcc bugreport (PR #16625) w.r.t a similar problem but it seems neither specific to gcc 3.4.3 nor do I see a resolution. Thanks Christoph I built both Boost and my application with gcc 3.4.3: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> LC_ALL=C g++ -v Reading specs from /opt/gcc/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/gcc/gcc-3.4.3 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread model: posix gcc version 3.4.3 The linker is: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> ld -v GNU ld version 2.15.91.0.2 20040727 (SuSE Linux) Boost was built using the following script: cludwig@cdcNT56:~/Cxx/gcc3.4/LaRed-0.1-BUILD> cat ~/Cxx/boost_1_32_0/build-boost_gcc34.sh #!/bin/bash bjam -d2 --with-pydebug \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <threading>multi" \ install bjam -d2 --without-python \ --prefix=$HOME/Cxx/gcc3.4/usr \ --builddir=$HOME/Cxx/gcc3.4/boost-1.32.0-build \ -sTOOLS=gcc \ -sBUILD="debug release <define>BOOST_DISABLE_THREADS <threading>single" \ install -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Gennaro Prota 10 May '05

10 May '05

--- Doug Gregor <dgregor(a)cs.indiana.edu> wrote: > The stream extraction operators for dynamic_bitset are failing on > CodeWarrior 9.4. See: http://tinyurl.com/addko > Is anyone familiar enough with the quirks of Metrowerks' iostreams to > fix this issue? Hi Doug, Jeremy and Howard unfortunately, due to a series of vicissitudes that would be too long to tell, I have no home connection at the moment (a situation that lasts from several months) and thus I can't work on CVS. Howard Hinnant is probably the person who knows Metrowerks compiler and library best. Howard? -- Genny. Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

2 2

[1.33.0] We're moving in the right direction...
by Doug Gregor 10 May '05

10 May '05

Since the last time I sent out status information, we've cleared up about 500 failures. Way to go! Let's keep on chipping away at those failures. Doug

1 0

[sandbox cvs][fsm] Rename from fsm -> statechart pending
by Andreas Huber 10 May '05

10 May '05

FYI: A few hours ago I've submitted a request to have the fsm directories in the sandbox renamed to statechart. After that has happened, checkouts of these modules will not compile until I've had the chance to apply the necessary changes. I'll let you know as soon as everything is in order again. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 1

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <loom.20050509T200130-152(a)post.gmane.org> nesotto(a)cs.aau.dk (Thorsten Ottosen) wrote (abridged): > > Also it requires users to #include <iterator> in order to use the new > > looping construct. There's precedent for that, though, because users > > must #include <typeinfo> to use typeid. I can't decide how I feel > > > about that. Perhaps there's another way. > > I spoke with several implementers and they all said that we need to > include some special header...otherwise it is very problematic to let > the compiler and standard library work together. Could you include a very specific header, eg called <for>, with just whatever it is "for" needs, and require that header to be #included by <iterator> and <vector> and the other containers? Or some similar mechanism... obviously there needs to be a way for end users to get the support for their own containers, and although I suppose just #including <iterator> would do, a smaller header might be better for the same reason that <vector> doesn't #include <iterator>. I appreciate that having standard headers document what other headers they include is a new thing. Would it be a problem in this case? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <427FB7C9.9030708(a)systemhaus-gruppe.de> sstrasser(a)systemhaus-gruppe.de (Stefan Strasser) wrote (abridged): > > Although it doesn't seem to say whether "vec" is hoisted, and the > > given translation suggests that it isn't. > > maybe "hoisting" was not the right word, I only know it from a post by > eric. "Hoisting" is fine for the purposes of this thread. > what I meant was copy-the-value-of-end()-at-the-start-of-the-loop. > and the proposal does that, see 3. It says end(vec) is hoisted, but doesn't say whether vec itself is hoisted. In "for (int i: vec )" is vec evaluated once or twice? I believe BOOST_FOR evaluates it exactly once. The translation given in the proposal is: using std::begin; // enable ADL using std::end; // ditto for( auto __begin = begin(vec), __end = end(vec); __begin != __end; ++__begin ) { int i = *__begin; std::cout << i; } which apparently evaluates vec twice. A variable __end is introduced explicitly for end(vec), but there is no analogous variable __vec. I guess we ought to find out for sure which it will be, and then make BOOST_FOR do the same. -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <427F7635.4010303(a)systemhaus-gruppe.de> sstrasser(a)systemhaus-gruppe.de (Stefan Strasser) wrote (abridged): > you might be interested in this document from the new c++0x mailing: > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html > > for the naming discussion, proposed syntax is for(int i : vec) > (personally I don't care if it's called BOOST_FOREACH or BOOST_FOR) I don't mind if it is BOOST_FOR_EACH or BOOST_FOR :-) > I've questioned in the past if it is expected behaviour to do > "hoisting". the proposal does. Although it doesn't seem to say whether "vec" is hoisted, and the given translation suggests that it isn't. I imagine that is an oversight in the presentation rather than the intended semantics. Interestingly he gives an example of an adaptor which could potentially be evaluated multiple times. The proposal says: The user is required to include the standard header <iterator> in which the default version of begin()/end() is defined which seems wrong to me. #include<vector> ought to be enough to use for with std::vector, if it's a built-in facility. -- Dave Harris, Nottingham, UK.

3 2

[gcc regressions] what's up with them
by Thorsten Ottosen 10 May '05

10 May '05

Hi, When I look at something like http://tinyurl.com/9v2as I assume the error is not in my library. Should/Can we do anything to fix it? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 12

[boost.assign] help with borland, sunpro & cw 8.3
by Thorsten Ottosen 10 May '05

10 May '05

Hi All, If anyone thinks these compilers are important to support in boost.assign, I will need your help to make these regressions run. Otherwise I will flag the errors as "expected failure". -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 5

boost log lib 1.3 compile failure w/gcc
by Neal Becker 10 May '05

10 May '05

I am looking at boost log library 1.3. I tried to compile "simple" example with gcc-3.4.3 (linux), here's what happens: g++ -o main main.cpp -I ../../../../ In file included from ../../../../boost/log/detail/ts.hpp:37, from ../../../../boost/log/log_fwd.hpp:34, from ../../../../boost/log/log.hpp:36, from ../../../../boost/log/log_impl.hpp:33, from main.cpp:4: ../../../../boost/log/detail/ts_posix.hpp: In constructor `boost::logging::threading::mutex::mutex()': ../../../../boost/log/detail/ts_posix.hpp:54: error: no matching function for call to `pthread_mutex_t::._10(int)' /usr/include/bits/pthreadtypes.h:87: note: candidates are: pthread_mutex_t::._10() /usr/include/bits/pthreadtypes.h:87: note: pthread_mutex_t::._10(const pthread_mutex_t&) In file included from ../../../../boost/log/log_impl.hpp:33, from main.cpp:4: ../../../../boost/log/log.hpp: At global scope: ../../../../boost/log/log.hpp:277: error: declaration of `bool boost::logging::logger_keeper_is_enabled<is_compile_time, is_enabled>::is_enabled(boost::logging::logger&) const' ../../../../boost/log/log.hpp:276: error: shadows template parm `bool is_enabled' ../../../../boost/log/log.hpp:277: error: declaration of `bool boost::logging::logger_keeper_is_enabled<is_compile_time, is_enabled>::is_enabled(boost::logging::logger&) const' ../../../../boost/log/log.hpp:276: error: shadows template parm `bool is_enabled' C

2 4

Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Gennaro Prota 10 May '05

10 May '05

--- Howard Hinnant <hinnant(a)twcny.rr.com> wrote: > I know the Metrowerks library inside/out. I started looking at this > last night but I'm pretty lost in the test code. I see. It's not the clearest code in the world. It is logically simple but a bit hard to debug due to the high number of combinations (and workarounds) involved. > > Here's what I have so far: > > Failure inside of: > > template<typename Stream, typename String> > static void stream_extractor(Bitset& b, > Stream& is, > String& str > ) > > at: > > if(stream_was_good) > BOOST_CHECK(remainder == str.substr(after_digits)); > > At this point remainder is a zero-length string, after_digits is 0 and > str is length 359. That's odd. after_digits is the position of the first character that follows 1s and 0s. The 359-characters str parameter should be the long string defined in bitset.hpp, thus you should have at least after_digits==359. I may be wrong because I don't have the necessary time and calm to check the code from the office but it might be worth examining this part. In particular if, for some reason, is_one_or_zero() is immediately returning false. > > On entry to this routine b has length 1 and that element is true. I > believe, but I am not positive that str is unmodified through this > test, despite being passed by reference (as opposed to const ref). > > I've so far been unable to determine the state of the stream is on > entry. But it looks completely hosed by the time the BOOST_CHECK is > triggered. For example the iostate has the value 0x7E even though the > highest numerical state it can possibly have is 0x07. That's odd too. I'll continue reading this thread via mail. Please keep me informed and sorry for not being able to dig into this myself. -- Genny Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

1 0

Standard Library Extension TR2 Call for Proposals
by Beman Dawes 10 May '05

10 May '05

The C++ Standards Committee has begun work on a second library technical report. A Call for Proposals is available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html --Beman

1 0

When 1.33 is released...
by Gordon Smith 10 May '05

10 May '05

As soon a 1.33 is released can we up the version number to 1_33_1 or such like in CVS, as this will make switching between HEAD and gold a lot easier? Gordon.

2 3

two boost.org doc section requests
by Max Khesin 10 May '05

10 May '05

1) Boost version in which the library was introduced. 2) The required header and object lib. I think these will improve the usability of documentation. Thanks, Max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Allocators in VC 8.0?
by Doug Gregor 10 May '05

10 May '05

Does anyone know of any weird behavior from allocators in VC 8.0? The Function library uses allocators when available, but the two tests of allocators (allocator_test and function_test) are failing on VC 8.0 (but not 7.1). From the config info, I see that BOOST_HAS_PARTIAL_STD_ALLOCATOR is defined but BOOST_NO_STD_ALLOCATOR is not (boost::function uses the latter). The actual failure is here: http://tinyurl.com/dq3lh Could someone with access to VC 8.0 (beta 2, I guess) check to see what is happening here? Doug

4 3

RE: [boost] Critique of Boost.Threads
by Jon Kalb 10 May '05

10 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes > Sent: Wednesday, May 04, 2005 6:31 AM > To: Boost mailing list > Subject: [boost] Critique of Boost.Threads > > With Kevlin Henney's permission, the following is a repost of > a message he recently posted on the C++ committee's library > reflector. It gives his views on Boost.Threads in the context > of possible standardization. > > --Beman > > ------- I have a (newbie) question about the joiner API. > And usage as follows: > > void void_task(); > int int_task(); > ... > joiner<void> wait_for_completion = thread(void_task); > joiner<int> wait_for_value = thread(int_task); > ... > int result = wait_for_value(); > wait_for_completion(); In the code snippet above does the line "int result = wait_for_value();" block until the completion of the thread? (It must or there is no way of knowing if the value of result is valid.) Is there a way for the client to avoid the block by checking whether or not thread is completed so that the call won't block... Some sort of wait_for_value.is_done()? -- Jon Kalb jonkalb(a)microsoft.com

3 2

[Integer] Libraries needs to be taught about Compaq Tru64 UNIX
by Douglas Gregor 10 May '05

10 May '05

Someone with access to Compaq Tru64 UNIX could probably fix the two COMSOFT errors in the Integer library: http://www.meta-comm.com/engineering/boost-regression/cvs-head/ developer/integer.html in a manner of minutes. It's likely some preprocessor magic that needs to be introduced. Doug

3 2

Re: Singleton Review: GCC compiler errors
by Jason Hise 10 May '05

10 May '05

Tobias Schwinger wrote: > Jason Hise wrote: > >> Sorry about the duplicate messages, thunderbird seemed to be having a >> problem. Hoping it's fixed now. >> >> Jason Hise wrote: >> >>> Tom Brinkman wrote: >>> >>>> Was the "singleton" library tested on GCC. I'm getting many >>>> compiler errors on 3.34. >>> >>> >>> >>> It was a while back, but many changes have been made since then. >>> I'll see if I can track down a copy of gcc to try compiling with it >>> myself. >> >> >> >> Actually, now that I'm looking into it it appears that Dev C++ uses a >> port of GCC by default, and I have successfully tested the latest >> version with Dev C++, getting no warnings or errors. What error >> messages are you getting? >> > > Are you sure you had all warnings enabled (-Wall) ? > > It was rather loud on my system. However, I could successfully build > tests and example with both 3.2 and 3.4 (both MinGW32). > > I'll send the output to you in private mail. Thanks for the heads up that I needed to use the -Wall option (I'm not used to working with gcc). I am now getting the same warnings that you sent to me, and am working to correct them. In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc? -Jason

8 10

[dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Doug Gregor 10 May '05

10 May '05

The stream extraction operators for dynamic_bitset are failing on CodeWarrior 9.4. See: http://tinyurl.com/addko Is anyone familiar enough with the quirks of Metrowerks' iostreams to fix this issue? Doug

1 0

[mpl] problems with VC7.0 + /Za
by Jonathan Turkanis 10 May '05

10 May '05

Hi, In porting Boost.Range to VC7, I discovered that several MPL headers do not compile if language extensions are disabled. I have verified the problem with the logical metafunctions (and, or, ...), the arithmetic metafunctions (plus, divides, ...) and the bitwise arithmetic functions. Jonathan

1 0

Re: [boost] Re: Calling a python function from C++ to update a progress display widget
by Ralf W. Grosse-Kunstleve 09 May '05

09 May '05

--- David Abrahams <dave(a)boost-consulting.com> wrote: > "Thierry Lam" <lam(a)pcigeomatics.com> writes: > > Hi Thierry, > > In the future, a better place for Boost.Python questions is > http://www.boost.org/more/mailing_lists.htm#cplussig That list is broken at the moment. :( I don't know why, and I am still waiting for a response from the Python people. Cheers, Ralf __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

BOOST_LOG & dlls
by Dirk Griffioen 09 May '05

09 May '05

Hi John, (I don't know if you get this but anyway). If I define & enable a log in a .lib but use it in a .dll somewhere else in the app (via declare in a .hpp file), I don't get no output from the dll: app.exe / \ log.lib stuff.dll (Compiles/links fine and the exe has output - but the dll has not.) Somehow, I want to avoid having a 'DECLARE + setup_logging' in all my dlls. Am I missing something? Best wishes, Dirk Griffioen ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this email in error please notify our system management at postmaster(a)optiver.com and immediately and permanently delete this message and any attachments. ********************************************

3 2

Formal Review: FOREACH macro
by Gennadiy Rozental 09 May '05

09 May '05

The formal review of Eric Nibbler's FOREACH macro starts today, April 25, and will continue until Monday, May 1st. I will be serving as review manager. BOOST_FOREACH is a macro that makes it simple to iterate over STL containers, ranges, arrays and null-terminated strings. Its performance approaches that of the hand-coded equivalent loop. BOOST_FOREACH uses Boost.Range can be extended to iterating user-defined collections by extending Boost.Range. The library is available at: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler foreach.zip Please note that the documentation is also available separately from the sources. It also can be viewed online at: http://boost-sandbox.sourceforge.net/libs/foreach The library is known to work (with different compliance levels) at least on the following compilers: * Visual C++ 7.1 * Visual C++ Whidbey Beta * Visual C++ 7.0 * Visual C++ 6.0 * gcc 3.3.3 * Intel for Windows 8.0 * Intel for Windows 7.0 * Comeau 4.3.3 When submitting reviews, please state explicitly whether or not you believe that the library should be accepted into Boost. For more information on the Boost formal review process, please see http://www.boost.org/more/formal_review_process.htm. Gennadiy

36 141

Re: [boost] (Named) Parameter Library
by Cromwell Enage 09 May '05

09 May '05

Daniel Wallin wrote: > Yes, that's correct. Although the code has been moved > to the Boost CVS and the namespace has been changed > to 'parameter'. Oh, that's where it is, now. Cool! A second look at the new code revealed that much of the type-extraction functionality I sought has already been implemented in <boost/parameter/aux_/arg_list.hpp>, under the nested struct 'key_value_type' (lines 71-78 and 186-196). However, this struct is defined only for older compilers. Can the definitions be moved out of the conditional macro blocks? That way, a type-extraction metafunction like the following would work: template < class ArgList, class KW, class Default > struct get_key_value_type : mpl::apply2< typename ArgList::key_value_type , KW , Default > { } > Thank you. I've merged your macro change into the > trunk, but I'm holding off the type-extraction code > until we have completed the changes we are currently > working on. No problem. Just don't take too long! My multi-state mazes project makes heavy use of this library. I'm currently working on documentation and a 2-D demo, and I hope to release it to the OS community in three or four weeks. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

archive's i/o register_type() signature (Bug#308291: please prevent compiler warning about unused variable)
by Domenico Andreoli 09 May '05

09 May '05

hi, boost debian package has been reported this bug/wish. is anybody able to commit this tiny fix? many thanks. cheers domenico ----- Forwarded message from martin f krafft <madduck(a)debian.org> ----- Date: Mon, 9 May 2005 09:59:43 +0200 From: martin f krafft <madduck(a)debian.org> Subject: Bug#308291: please prevent compiler warning about unused variable Some of us like to use -Werror. Some of boost does not. Please consider the following, non-intrusive and tested patches: diff -u /tmp/interface_oarchive.hpp /usr/include/boost/archive/detail/interface_oarchive.hpp --- /tmp/interface_oarchive.hpp 2005-05-09 09:54:24.897652747 +0200 +++ /usr/include/boost/archive/detail/interface_oarchive.hpp 2005-05-09 09:54:56.611522300 +0200 @@ -57,7 +57,7 @@ } template<class T> - const basic_pointer_oserializer * register_type(T * t = NULL){ + const basic_pointer_oserializer * register_type(T * = NULL){ const basic_pointer_oserializer & bpos = instantiate_pointer_oserializer( static_cast<Archive *>(NULL), diff -u /tmp/interface_iarchive.hpp /usr/include/boost/archive/detail/interface_iarchive.hpp --- /tmp/interface_iarchive.hpp 2005-05-09 09:58:24.366913089 +0200 +++ /usr/include/boost/archive/detail/interface_iarchive.hpp 2005-05-09 09:58:31.519755952 +0200 @@ -53,7 +53,7 @@ } template<class T> - const basic_pointer_iserializer * register_type(T * t = NULL){ + const basic_pointer_iserializer * register_type(T * = NULL){ const basic_pointer_iserializer & bpis = archive::detail::instantiate_pointer_iserializer( static_cast<Archive *>(NULL), ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

1 0

Re: [boost] Visual Studio 2005 Beta 2 + Multi Index
by JOAQUIN LOPEZ MU?Z 09 May '05

09 May '05

----- Mensaje original ----- De: Gordon Smith <schmoo2k(a)hotmail.com> Fecha: Viernes, Abril 22, 2005 5:43 pm Asunto: [boost] Visual Studio 2005 Beta 2 + Multi Index > The following stdafx.h for a vanilla console app kills the beta 2 > compiler > (I think it creates a corrupt PCH file): > > #pragma once > > #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from > Windows > headers > #include <windows.h> > #include <tchar.h> > > // BOOST --- > #include <boost/multi_index/sequenced_index.hpp> > #include <boost/multi_index/ordered_index.hpp> > Hi Gordon, excuse my late answering, somehow I just didn't see your post amidst the current flow of messages. Did this work for MSVC 8.0 beta 1? I'm afraid I cannot help much here except suggest that you try to report this to the MSVC dev team: http://lab.msdn.microsoft.com/productfeedback/ Also, please try deleting all intermediate files before doing a fresh compile --this is sometimes helpful specially in regard to PCHs. If you make any progress or need some help please keep me informed. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] [1.33] type traits VC8 fixes and the release schedule
by Ralf W. Grosse-Kunstleve 09 May '05

09 May '05

--- John Maddock <john(a)johnmaddock.co.uk> wrote: > Anyway I'll go ahead with the change, and if it bytes back too badly, I'll > just revert the lot. Some positive feedback: I tried the changes out on a whole bunch of platforms (http://cci.lbl.gov/cctbx_build/show_results.cgi?build_tag=2005_05_08_0558) and the CVS from about 24 hours ago works flawlessly everywhere. I am mainly testing Boost.Python compilation. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Calling a python function from C++ to update a progress display widget
by Thierry Lam 09 May '05

09 May '05

Let's say I have the following in a Python file called progress.py: pbar = gtk.ProgressBar() def updateBar(): pbar.puls() In C++: for ( int i = 0; i < 10; i++ ) // Call the python method updateBar() which is not a member of any class in progress.py How do I do it? I'm aware of the following 2 functions in boost: call<ResultType>(callable_object, a1, a2... aN); call_method<ResultType>(self_object, "method-name", a1, a2... aN); Can I see an example on how to use them? My goal is to display the progress bar widget live while the for loop is counting from 0 to 9.

2 1

[string algorithms] feature request - case-insensitive less
by Joe Gottman 09 May '05

09 May '05

I was looking at the string algorithms library, and I saw it had a case-insensitive equals function, iequals, as well as a predicate class, is_iequal. It would be nice if there were a case-insensitive less-than function and predicate as well. This would facilitate case-insensitive sorting, and set or maps which are sorted case-insensitively. Joe Gottman

4 6

[filesystem] gcc-3.4.3, fstream_test
by Rene Rivera 09 May '05

09 May '05

For this sole failure on the tests that I run: http://tinyurl.com/92zns I did some investigation and narrowed the problem down to this: ===basic_iostream_char_test.cpp=== #include <fstream> struct my_fstream : public std::basic_fstream<char> { my_fstream() : std::basic_fstream<char>("basic_iostream_char_test.cpp") { } }; int main(int argc, char** argv) { my_fstream f; } ===basic_iostream_char_test.cpp=== Which gives a link error of: undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()' And AFAICT that particular dtor is not in libstdc++. And for that matter the entire std::basic_iostream<char,..> instance is missing. The strange aspect of this is that this exact test passes on Martin's tests. And of course it's only with this particular gcc. When I compile with 3.3.5, on the same machine, the symbols exist. Could others try compiling the above code? Just need to see if it's just my machine that has this problem before I file a GCC bug report. --grafik

4 5

RE: [boost] Logging Library -- Formal Review Request
by Roman Yakovenko 08 May '05

08 May '05

John Torjo wrote: > > I've just updated the Boost Log Library: > http://torjo.com/code/logging-v132.zip > > > I would also like to ask for a _Formal Review_. > > > > The Boost Log Library is a small library, who: > * makes it very easy to declare/define new logs > * allows you very simple access to logs > * allows for log hierarchies, and for modifying log hierarchies > * allows for easy and efficient enabling/disabling of > logs/log hierarchies > * allows for easy manipulation of log behaviors > (the log's destination(s) and/or adjusting the original message) > * is thread-safe > > Using the library in code is easy and straightforward: > > int i = 1, j = 2, k = 3; > BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << > std::endl; > BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; > BOOST_LOG(info) << "I just wanted to tell you something...."; > Hi. If I understand right the code, even if log is disabled, I do pay for constructing log messages. Am I right? If so why do you force this? Roman

13 22

Boost.Test: to-do
by Gennadiy Rozental 08 May '05

08 May '05

Hi, Here is a list of some of the to-do items that I plan to address soon: * I plan finish finally update for CLA support * Once it's done: selective test cases run by name * Boost.Test thread safety need to be achieved at least if BOOST_TEST_THREAD_SAFE is defined. This one will require separate discussion * Some performance testing tools (aka profiler). Unless somebody else will come up with something like this * Build info feature needs to be updated: there are at least two different "build infos": library build and test module build * Auto linking for Boost.Test. Also I really need to work on more tutorial documentation. Two projects that could be very interesting. But I may not be able to do it by myself: * I would like to write an add-on for Visual Studio to automate test case/test modules generation * I may be convenient to have an external test runner: utility that load some libraries dynamically initialize test it contains and execute all/some of them. I was able to make Boost.Test work sunpro 5.3. HP compiler is still a mystery. Any help appreciated. I've made an attempt to implement a DLL version of Boost.Test on windows. And failed. As things looks now it's impossible or at least may require some interface changes. Any help in this direction are greatly appreciated either. If you have any suggestions (or made them before and I forgot about it), here would be a good place to speak up. Regards, Gennadiy

2 2

RE: [boost] [MPL] is_sequence problem
by Brian Braatz 08 May '05

08 May '05

Could it be as simple as missing the namespace on the is_sqeuence<> call? > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 5:46 PM > To: boost(a)lists.boost.org > Subject: [boost] [MPL] is_sequence problem > > Hi, > > I have a problem with this code snippet: > > #include <boost/mpl/is_sequence.hpp> > > int > main() > { > using boost::mpl::int_; > using boost::mpl::is_sequence; > bool b = is_sequence<int_<0> >::value; > } > > VC7.1 complains: > > C:\dev\boost\boost\mpl\aux_\begin_end_impl.hpp(35) : error C2039: > 'begin' : is not a member of 'boost::mpl::int_<N>' > with > [ > N=0 > ] > C:\dev\boost\boost\mpl\begin_end.hpp(35) : see reference to > class template instantiation > 'boost::mpl::begin_impl<Tag>::apply<Sequence>' being compiled > with > [ > Tag=boost::mpl::begin<boost::mpl::int_<0>>::tag_, > Sequence=boost::mpl::int_<0> > ] > C:\dev\boost\boost\mpl\is_sequence.hpp(94) : see reference to > class template instantiation 'boost::mpl::begin<Sequence>' being compiled > with > [ > Sequence=boost::mpl::int_<0> > ] > C:\dev\test\mpl_is_sequence.cpp(8) : see reference to class > template instantiation 'boost::mpl::is_sequence<T>' being compiled > with > [ > T=boost::mpl::int_<0> > ] > C:\dev\boost\boost\mpl\aux_\begin_end_impl.hpp(35) : error C2955: > 'boost::mpl::begin' : use of class template requires template argument > list > C:\dev\boost\boost\mpl\begin_end.hpp(38) : see declaration of > 'boost::mpl::begin' > C:\dev\boost\boost\mpl\begin_end.hpp(35) : error C2955: > 'boost::mpl::begin' : use of class template requires template argument > list > C:\dev\boost\boost\mpl\begin_end.hpp(38) : see declaration of > 'boost::mpl::begin' > C:\dev\boost\boost\mpl\is_sequence.hpp(94) : error C3203: 'begin' : > class template invalid as template argument for template parameter 'T', > expected a real type > >Exit code: 2 > > Any hints? I am relying on is_sequence to return false in this case. > Comeau and g++ throws up too. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

8 12

No -fcoalesce-templates with GCC 4.0 on Mac OS X Tiger
by Patrick Hartling 08 May '05

08 May '05

I haven't seen any posts about this, so please pardon me if I have missed it, but Boost does not currently build on Mac OS X Tiger with the 'darwin' toolset because the option -fcoalesce-templates has been removed from the Apple build of GCC 4.0. I have made simple modifications to my checked out copy of the latest Boost source to allow the libraries I need to build, but my changes would break the usability of Boost libraries on previous versions of OS X that need -fcoalesce-templates. I would be happy to submit a patch and run any tests if someone could suggest how I would go about modifying boost/tools/build/v1/darwin-tools.jam in a backwards compatible manner. Thanks. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/

2 3

Strange mail from this list?
by Liu Jin 08 May '05

08 May '05

Hi boosters, Recently I've got a lot of empty messages (a sample below) from the list. Is there something wrong with my mail client, or it's normal group traffic? Thanks. Jin [sample] X-From-Line: boost-bounces(a)lists.boost.org Sun May 8 00:22:21 2005 Received: from milliways.osl.iu.edu (unknown [129.79.245.239]) by 192.168.9.79 (Coremail) with SMTP id GMAWgzzrfELex+8A.1 for <cpp(a)vip.163.com>; Sun, 08 May 2005 00:22:21 +0800 (CST) X-Originating-IP: [129.79.245.239] aaazzzaaazzzaaazzzaaazzzaaazzz X-Gnus-Mail-Source: pop:cpp@pop.vip.163.com Message-Id: <427CEB3D.3B6F3C.00995> Date: Sun, 8 May 2005 00:22:21 +0800 (CST) From: boost-bounces(a)lists.boost.org X-Content-Length: 1 Lines: 2 Xref: CPP_COMPUTER mail.personal:1109

2 1

[iostreams] Compilation errors with MSVC 8
by Keith MacDonald 08 May '05

08 May '05

When building CVS Boost with MSVC 8 beta 2 (http://lab.msdn.microsoft.com/vs2005/) it generated the errors below for iostreams. operations.hpp has a mixture of line endings, and symmetric_filter_adapter_impl is missing a return type, so I guess it's telling the truth! - KM F:\CVS\boost\boost/iostreams/operations.hpp : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format F:\CVS\boost\boost/type_traits/is_abstract.hpp(81) : warning C4800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning) F:\CVS\boost\boost/type_traits/is_abstract.hpp(93) : see reference to class template instantiation 'boost::detail::is_abstract_imp2<T>' being compiled F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : error C2063: 'symmetric_filter_adapter_impl' : not a function F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : error C2888: 'symmetric_filter_adapter<SymmetricFilter,Alloc>::symmetric_filter_adapter_impl symmetric_filter_adapter_impl' : symbol cannot be defined within namespace 'iostreams' F:\CVS\boost\boost/iostreams/filter/symmetric_filter_adapter.hpp(303) : fatal error C1903: unable to recover from previous error(s); stopping compilation

3 4

[range] CW on MacOSX failures...
by Rene Rivera 07 May '05

07 May '05

Could someone explain what the intent of this change is: http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/range/test/string.cp… http://tinyurl.com/8efhq Specifically the "#define _MSL_USING_NAMESPACE 1"? That is causing duplicate def errors, as this is supposed to be an internal MSL macro. -- -- 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

1 0

[numeric/conversion] CW and VC8 fixes.
by Rene Rivera 07 May '05

07 May '05

All the tests for this library should now pass for all CodeWarrior versions. I also fixed two files with bad EOLs, which will likely fix the problems with VC8. Note.. if you see this kind of error on the VC8 logs: error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format It's because of EOLs problems also reported at: http://www.boost.org/regression-logs/inspection_report.html -- -- 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

1 0

Re: [boost] Re: BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 07 May '05

07 May '05

In-Reply-To: <d5d7h5$3cp$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > While this is discussible position, I did not see you prove you > point enough to reject a submission. As I said, that wasn't my reason for voting against the proposal. However, I'm content with the final result; I don't expect or want to overturn it. -- Dave Harris, Nottingham, UK.

1 0

[date_time] CodeWarrior fixes.
by Rene Rivera 07 May '05

07 May '05

I put in some fixes to clear out some of the CodeWarrior regressions. Only four types of problems still exist: 1. There are DLL tests that use std::locale, directly or indirectly I don't know, but they should be marked as expected-to-fail. 2. There are tests that fail because boost.serialization lib fails to build. I'll eventually get to checking why that doesn't build. 3. There are two tests that now compile, but fail at runtime with an access violation. From previous experience it looks like accessing a vtable method through a NULL pointer. The tests are the two *_time_input_facet. 4. There's an unexplained compiler confusion at: boost\date_time\date_parsing.hpp:262: data type is incomplete Possibly the compiler is trying to instantiate too early? Don't really know. -- -- 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

2 1

[Test] Thread-safety
by Cliff Green 07 May '05

07 May '05

Silly me - I should have looked in the Boost.Test Open Issues page a couple of days ago instead of wasting my time trying to solve some multi-threading problems in my own code. So a couple of enhancement requests (for Gennadiy, or appropriate person): 1. Please state clearly in the Boost.Test documentation that it is not thread-safe. I looked all through the pages (both the current release and the 1.31 release) but the only place I find mention of thread-unsafety is in the Open Issues page. The FAQ page would also be a good place to mention Boost.Test thread-unsafety, besides the main page (and places like Usage Recommendations, Examples, Compilation, etc). 2. Please consider adding thread-safeness to the Boost.Test libraries. I know this is not a simple request, and there may be other priorities ... but many of my (and my team's) unit tests are multi-threaded, and it's a shame to not be able to use Boost.Test (or even know which, if any, parts are thread-safe). It's a nice testing framework, IMO. Note that I don't need the whole library itself to be threaded, just to be able to do things like BOOST_MESSAGE and BOOST_EQUAL within my own testing threads. (I'll offer whatever help I can provide, within the constraints of my available time.) Many thanks! Cliff

4 4

Re: [boost] BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 07 May '05

07 May '05

In-Reply-To: <989aceac050505060373e68a1(a)mail.gmail.com> caleb.epstein(a)gmail.com (Caleb Epstein) wrote (abridged): > > What about the name? Shouldn't it be "BOOST_FOR_EACH"? > > Why? Because of the distinct English words? Yes. And for consistency with other C++ macros, algorithms and keywords. I've argued at greater length in the other thread. -- Dave Harris, Nottingham, UK.

5 5

Re: [boost] Singleton Review: GCC compiler errors
by Jason Hise 06 May '05

06 May '05

Sorry about the duplicate messages, thunderbird seemed to be having a problem. Hoping it's fixed now. Jason Hise wrote: > Tom Brinkman wrote: > >> Was the "singleton" library tested on GCC. I'm getting many compiler >> errors on 3.34. > > It was a while back, but many changes have been made since then. I'll > see if I can track down a copy of gcc to try compiling with it myself. Actually, now that I'm looking into it it appears that Dev C++ uses a port of GCC by default, and I have successfully tested the latest version with Dev C++, getting no warnings or errors. What error messages are you getting? -Jason

3 2

[test] PATCH: putenv usage incorrect
by Caleb Epstein 06 May '05

06 May '05

http://tinyurl.com/72sj8 This test is failing on numerous platforms, some for the fact that "putenv" takes a non-const char* (Linux, Solaris, perhaps others). Attached is a patch for environment.ipp which changes it to use the setenv function on non-Windows systems. I believe this is a POSIX standard function (via BSD). I think this cleans up the code a bit, removing the raising of getenv/putenv into namespace std, when they are I think clearly non-std functions. -- Caleb Epstein caleb dot epstein at gmail dot com

3 6

[property_map] test program fix.
by John Maddock 06 May '05

06 May '05

The following fix gets the property_map test that's currently failing with several high-quality compilers, building OK (at least with vc7.1, I can't test with MWCW, but that compiler has the same issue with the existing test so it should fix it). Is this OK to commit? John. diff -r1.1 dynamic_properties_test.cpp 110c110 < BOOST_CHECK(get<std::string>("nada",props,std::string("3.14")) == "pi"); --- > BOOST_CHECK(get("nada",props,std::string("3.14")) == "pi");

1 0

[Integer] Mac OS X: WCHAR_MIN != std::numeric_limits<wchar_t>::min()
by Douglas Gregor 06 May '05

06 May '05

The title says it all: the Mac OS X system headers are inconsistent about the minimum value of a wchar_t. The C++ <limits> header has it right, but the definition of WCHAR_MIN in <cwchar>/<wchar.h> is wrong (0). If there are no complains, I'm going to commit the following patch. I don't believe this will affect CodeWarrior on the Mac, but I can't test against it. Index: integer_traits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/integer_traits.hpp,v retrieving revision 1.26 diff -u -r1.26 integer_traits.hpp --- integer_traits.hpp 17 Dec 2004 11:56:15 -0000 1.26 +++ integer_traits.hpp 6 May 2005 15:46:36 -0000 @@ -88,7 +88,9 @@ template<> class integer_traits<wchar_t> : public std::numeric_limits<wchar_t>, -#if defined(WCHAR_MIN) && defined(WCHAR_MAX) + // Don't trust WCHAR_MIN and WCHAR_MAX with Mac OS X's native + // library: they are wrong! +#if defined(WCHAR_MIN) && defined(WCHAR_MAX) && !defined(__APPLE__) public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX> #elif defined(__BORLANDC__) || defined(__CYGWIN__) || defined(__MINGW32__) || (defined(__BEOS__) && defined(__GNUC__)) // No WCHAR_MIN and WCHAR_MAX, whar_t is short and unsigned: Doug

1 0

building boost
by Stefan Seefeld 06 May '05

06 May '05

I'm using some of the recent features of boost, and so I updated regularly from cvs and recompile. However, as was noted before, a simple 'bjam' will take a *lot* of time, and consume a *lot* of disk space. Right now I'm seeing almost 900 MB in my boost tree and that doesn't even count all the space taken by boost once 'bjam install' has finished. I'd really like to see an option to instruct boost.build only to produce one set of libraries, such as release-multithread-shared (falling back to static if shared isn't available). I don't care how such an option would be spelled, and whether that would become the default build target or not. But the current situation is quite wastefull, IMO. Thanks, Stefan

2 2

[program_option] allow_unregistered now works
by Vladimir Prus 06 May '05

06 May '05

Since this was the most requested change for program_options, I though I'd post specific announcement. I've committed a change that finally makes command_line_parser::allow_unregistered to work as expected. Assuming you get command line like: --foo=10 --bar=15 --biz 5 -cd -d10 and registered options are "foo" and "-c", where "-c" takes no value, parsing that command line will give you the following list of options: ("foo", "10") ("bar", "15") * ("biz", ) * ("5") (positional) ("-c", ) ("-d", ) * ("-d", "10) * The 'option' instances corresponding to option marked with '*' will have 'unregistered' member set to true. With that information it's possible to: 1. Collect all unregistered option as process them separately. 2. Construct a new command line from unregistered options and pass it to some application. In the above example, reconstructed command like would be --bar=15 --biz 5 -d -d10 There are some notes of interest. First, the option class don't keep the original tokens it was created from. The unregistered option can technically arrive from user-provided 'additional parser' where 'original tokens' are not even present. Second, for 'sticky' short options, like '-cd' above, the library can break them in parts. Again, in example we get: ("-c", ) ("-d", ) * The 'c' letter is recognized, and the 'd' letter is not. I find this behaviour better than marking the entire '-cd' as unrecognised. Finally, the new functionality might not work nice with long options that start with a single dash (allow_long_disguise style option): -foo will be considered as short option '-f' with value 'oo', and never as long option 'foo'. Feedback is appreciated! I was also asked for 'allow_unregistered' support for config file. I agree this might be good, but given that config file never supported it in any form, it's clearly a new feature, and will have to wait till 1.33 is released. - Volodya

3 3

[policy_ptr]std_ptrs.hpp's include target missing & incomplete shared_ptr emulation
by Larry Evans 06 May '05

06 May '05

The file: std_ptrs.hpp contains: #include "policy/boost.hpp" yet there's no policy/boost.hpp. However, there is: boost_policies.hpp However, in that file, the shared_storage class, contains: detail::shared_count count_; IOW, count_, unlike that in shared_ptr, contains no information about the type of pointee_; hence, I can't understand how policy_ptr's smart_ptr<...>, can emulate boost's shared_ptr with existing policies. What have I missed?

2 3

[patch] typo in more/getting_started.html
by Jonathan Wakely 06 May '05

06 May '05

Simple typo

2 1

[filesystem] Operations predicates
by Beman Dawes 06 May '05

06 May '05

I've completed an analysis of expectations for the exists() and is_xxx() family of functions, and the previously suggested status() and symlink_status() functions. See http://www.esva.net/~beman/filesystem_operations_predicates.htm Thanks to Peter Dimov, Rob Stewart, and Jeff Garland for their suggestions. Errors are mine alone. Comments? --Beman

7 41

Re: Boost filesystem documentation
by James Gregory 06 May '05

06 May '05

> You are right that there is a clash. But it seems to me std::runtime_error > should be the base class, so it is the implementation that is wrong. > > Comments? > > --Beman 1. The boost guidelines at http://www.boost.org/more/error_handling.html say "Derive your exception class from std::exception. Except in *very* rare circumstances where you can't afford the cost of a virtual table, std::exception makes a reasonable exception base class" 2. But runtime_error does derive from std::exception, and the error is a run time error 3. Whilst I'm here, I would also like to point out the following silly code I need to use boost filesystem for a program designed to run in Linux and Windows: #ifdef __linux__ fs::path::default_name_check(fs::windows_name); #else //ie we are compiling for Windows fs::path::default_name_check(fs::native); #endif If I use fs::native at all times then I cannot use paths with spaces in under Linux, but if I use fs::windows_name at all times then I cannot use a colon to specify drive names in Windows (e.g. C:\). James

2 1

boost configuration issue
by François Dumont 06 May '05

06 May '05

Hello I think I found a configuration issue while building boost 1.32.0 with VC .Net 2003 (VC71) using STLport 5.0 beta (latest from cvs STLPORT_5_0 branch). Maybe someone already notive this problem but the latest boost CVS version still show it. With the STLport lib the macro configuration is : - BOOST_NO_INTRINSIC_WCHAR_T defined - BOOST_NO_STD_WSTRING _not_ defined, wstring are supported Thanks to the BOOST_NO_STD_WSTRING macro the date_time lib instanciate code for wstring specific type. For instance in libs/date_time/src/gregorian/greg_month.cpp you will find a block of code in a #ifndef BOOST_NO_STD_WSTRING block. The date_time lib use the lexical_cast tool. But the lexical_cast tool do not care about BOOST_NO_STD_WSTRING and rather check, among other macros, BOOST_NO_INTRINSIC_WCHAR_T and so do not grant the necessary specialization for wchar_t and wstring. The error message is then something like: D:\boost_1_32_0\boost/lexical_cast.hpp(137): error: no operator "<<" matches these operands operand types are: std::basic_stringstream<wchar_t, std::char_traits<wchar_t> , std::allocator<wchar_t> > << const std::basic_string<char, std::char_traits<char> , std::allocator<char>> return stream << input; Sorry for not having the accurate message but I have the compiler on an other computer. I see 2 possible solutions to this problem: - concider that there is no wstring support if there is no intrinsic wchar_t support. - make lexical_cast less strict and do not require intrinsic wchar_t support. Bests

2 2

RE: [boost] Re: [MPL] is_sequence problem
by Brian Braatz 06 May '05

06 May '05

This is not my problem (just piqued my interest :) ) But for grins I tried this on 7.1 boost::mpl::is_sequence< list<int> >; // compiles boost::mpl::is_sequence< int_<0> >; // compiles boost::mpl::is_sequence< int<0> >; // doesnt compile boost::mpl::is_sequence< int_<0> >::value; // doesnt compile so replacing with int didn't work > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 10:25 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [MPL] is_sequence problem > > Brian Braatz wrote: > > Could it be as simple as missing the namespace on the is_sqeuence<> > > call? > > Have you tried it? If it was, I wouldn't have bothered the list ;-) > Try replacing int_<0> with int. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: [boost] Re: [MPL] is_sequence problem
by Brian Braatz 06 May '05

06 May '05

Hehehe There are others out there either on another timezone, or not sleeping :) I put the code into VC71 and have been playing with it. I got the same error. (it WASN'T namespace weirdness with VC) (I get soo grouchy with VC I tend to blame the compiler too quickly) I then degenerated into digging through the MPL reference and trying different examples in the project. As of yet, though nothing useful to report. I think I am going to bed. I > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 10:54 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [MPL] is_sequence problem > > Joel wrote: > > Brian Braatz wrote: > > > >> Could it be as simple as missing the namespace on the is_sqeuence<> > >> call? > > > > > > Have you tried it? If it was, I wouldn't have bothered the list ;-) > > Try replacing int_<0> with int. > > I think the problem is the way mpl::is_sequence is implemented. > It tries to detect the presence of a "tag" typedef and a "begin" > typedef and concludes that a type is an mpl::sequence if it > has both. I've complained a long time ago about this. I think > this behavior is error prone. It's quite easy to come up with > a situation where I have a type T with a "tag" and a "begin" > but is not an MPL sequence. There must be a better way. MPL > should not monopolize on the usage of "tag" and a "begin" > in a type. > > Anyway, in any case, is_sequence<int_<0> >::value should never > fail to compile. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Re: [MPL] is_sequence problem
by Brian Braatz 06 May '05

06 May '05

I only suggest that because with VC I have seen weirdness like that. I.e. you THINK you have brought something in with a using, but it , in some weird case, doesn't work for whatever reason. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joel > Sent: Thursday, May 05, 2005 10:25 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: [MPL] is_sequence problem > > Brian Braatz wrote: > > Could it be as simple as missing the namespace on the is_sqeuence<> > > call? > > Have you tried it? If it was, I wouldn't have bothered the list ;-) > Try replacing int_<0> with int. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Fwd: [boost] [patch] lambda bug with GCC debug mode
by Jonathan Wakely 06 May '05

06 May '05

Ping! Originally posted a few weeks ago. I've CC'd Jaakko's SourceForge account, should I raise a sourceforge bug instead? jon

3 2

What is the easiest way to assign mulitply value for a defined number array?
by zlf 06 May '05

06 May '05

Hi all, What is the easiest way to assign mulitply value for a defined number array? Assigning mulitply elements' value when defining like this will be OK. int test [ 2 ] = { 1 , 2 }; If I want to assign value for the number array [test] after defining it. I only know I can achieve this by the following step. int test [ 2 ]; test [ 0 ] = 1; test [ 1 ] = 2; [int test [ 2 ]; test = { 1 , 2 };] seems easy and reasonable. But executing it will get a compile error. What is the easiest way to assign mulitply value for a defined number array? Thx zlf

2 2

RE: [boost] Re: Logging Library over Iostreams? (was Logging Library-- Formal Review Request)
by Brian Braatz 06 May '05

06 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Darryl Green > In what way isn't this a "well designed bolt on to IOSTREAMS"? I can see > is that > it is more general than is necessary if one takes the view that iostreams > provide all the facilities/customisation points you could need. I'm not of > that > view. [Brian Braatz Writes:] Hmm.. I can better explain what I am suggesting this way: There are a lot of smart people throwing a lot of good points of variations at the logging library. Logging is somewhat of an issue that is difficult to solve because you cannot make everyone happy (everyone seems to have varying needs) I see the logging concept as either a device or a sink in iostreams. One that has the right balance of concrete design and points where the user can supply functionality (policies) to allow for at least speaking to most of the issues. I see this device as something I can build using template programming to meet my needs. I also see the dynamic filtering in iostreams as something very useful for production usage of logging. I see how to output and split and or manipulate the log output as something that, again, rides on iostreams. Things for example I PERSONALLY need out of a log: 1- Might Need to be able to re-direct to the ACE logging service 2- Windows Event Log 3- A file on disk 4- I might need multiple files on disk- one that is HIGH LEVEL interesting information and another that is the details (previous work has shown me this works very well in a production environment) 5- I might need to send the log to different "devices' simultaneously -I.e. another program over a socket, and my normal logging file. Because this is an issue that has so many perspectives, my suggestion is to think along the following lines: 1- Put enough policies into the design so the user can get what they need out of the lib (everyone has very different needs is my assumption) 2- Think about making the logging lib a conceptual extension of iostreams in design

2 1

[MPL] is_sequence problem
by Joel 06 May '05

06 May '05

Hi, I have a problem with this code snippet: #include <boost/mpl/is_sequence.hpp> int main() { using boost::mpl::int_; using boost::mpl::is_sequence; bool b = is_sequence<int_<0> >::value; } VC7.1 complains: C:\dev\boost\boost\mpl\aux_\begin_end_impl.hpp(35) : error C2039: 'begin' : is not a member of 'boost::mpl::int_<N>' with [ N=0 ] C:\dev\boost\boost\mpl\begin_end.hpp(35) : see reference to class template instantiation 'boost::mpl::begin_impl<Tag>::apply<Sequence>' being compiled with [ Tag=boost::mpl::begin<boost::mpl::int_<0>>::tag_, Sequence=boost::mpl::int_<0> ] C:\dev\boost\boost\mpl\is_sequence.hpp(94) : see reference to class template instantiation 'boost::mpl::begin<Sequence>' being compiled with [ Sequence=boost::mpl::int_<0> ] C:\dev\test\mpl_is_sequence.cpp(8) : see reference to class template instantiation 'boost::mpl::is_sequence<T>' being compiled with [ T=boost::mpl::int_<0> ] C:\dev\boost\boost\mpl\aux_\begin_end_impl.hpp(35) : error C2955: 'boost::mpl::begin' : use of class template requires template argument list C:\dev\boost\boost\mpl\begin_end.hpp(38) : see declaration of 'boost::mpl::begin' C:\dev\boost\boost\mpl\begin_end.hpp(35) : error C2955: 'boost::mpl::begin' : use of class template requires template argument list C:\dev\boost\boost\mpl\begin_end.hpp(38) : see declaration of 'boost::mpl::begin' C:\dev\boost\boost\mpl\is_sequence.hpp(94) : error C3203: 'begin' : class template invalid as template argument for template parameter 'T', expected a real type >Exit code: 2 Any hints? I am relying on is_sequence to return false in this case. Comeau and g++ throws up too. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 0

(Another) socket streams library
by pedro.lamarao＠mndfck.org 05 May '05

05 May '05

Hello, all. I see everybody has been talking about a networking library for a long while. Checking the wiki, I see that my own project has escaped attention. So, here it goes for the examination of the experts: http://socketstream.sourceforge.net/ -- Pedro Lamarão

11 47

[CVS] How to move a module from boost-sandbox to boost
by Andreas Huber 05 May '05

05 May '05

Dear Boosters At some point I will have to move the directories containing the Boost.Statechart library from the boost-sandbox repository to the boost repository. Is there any way to do this without losing the CVS history? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

BOOST_FOREACH and 1.33.0
by Russell Hind 05 May '05

05 May '05

This was posted under the 'BOOST_FOREACH review results' thread but was suggested to be posted as a separate thread so others can comment on it (including the review manager and author). What do people think? Could it be pushed in to 1.33.0 or do we wait for 1.34.0 before it is added to an official release? Cheers Russell -------- Original Message -------- Pavel Vozenilek wrote: > > Perhaps exception could be made - it is mature, used in apps > and the documentation can be updated quickly. > > It may serve as starting point for people exploring other libraries. > I would like to see it in there too. AFAICT, it doesn't require any changes to other libraries (the bcc32 addressof problem has already been patched in CVS) so its impact should be minimal to none on regression tests. I guess its would still then be up to Eric to decide if the current tests and docs are where he'd like them to be for general release after the review. Cheers Russell

5 6

[1.33] type traits VC8 fixes and the release schedule
by John Maddock 05 May '05

05 May '05

What's the timescale for 1.33 at present? I have some VC-8 specific fixes for type traits that hook up the compiler's intrinsic type traits support into our traits classes: these patches make VC8 the first compiler to "just do the right thing" with every single trait. That's a big milestone IMO! Assuming VC8 will be release before Boost-1.34 (which seems likely), I'd like to commit these to cvs, but won't do so if we're too close to release (as long as there's at least 10 days or so to go, then there's enough time to check for possible regressions - especially as only one compiler should be affected - and there are no regressions for me locally with gcc/vc++/borland/intel). Thoughts? Thanks, John.

3 3

[1.33.0] Need more help fixing bugs!
by Douglas Gregor 05 May '05

05 May '05

We're making progress fixing bugs for 1.33.0, but we still have over 2000 failures on our target set of compilers. We need your help! Doug

1 0

socketstreams for boost?
by Peter Sommerlad 05 May '05

05 May '05

Hello all I met some of you on the list at this years ACCU conference in Oxford. However, I forgot to ask something I might supply to boost. I have a long experience with writing and using iostream adapters for TCP-sockets (in 24x7 production servers written in C++). A quick look at boost seems to me that this part of IO is lacking. My current solution is not yet fit for inclusion into boost, because it is still using "legacy" C++ and requires some infrastructure from another foundation library (mine :-). However, I'd like to modernize that library and the surrounding MT-server-framework in the future. If such a work (sockt-iostream) could go into boost, I would be happy to use boost as a new foundation for my framework. I'd like to hear, a) if there is interest in iostream for sockets b) if there is already a solution pending for inclusion (to review it) c) if there are people working on it who I might join Thanks for giving me some answer encouring me to work on that topic...:-) Yours Peter. -- -- Peter Sommerlad Erlenstrasse 79 CH-8832 Wollerau tel +41 1 687 44 74 fax +41 1 687 44 71 mobile +41 79 432 23 32 mailto:psommerlad@hispeed.ch

4 3

boost serialization: unregistered_class exception
by Keith McNeill 05 May '05

05 May '05

Using boost serialization I'm getting a unregistered_class exception. I know how to solve the problem once I figure out what class is having the problem. Figuring out which class is the problem can be a real pain when you have lots of templates. Is there anyway to get more information from boost serialization as to exactly what class is unregistered? Or is there anyway to inspect the archive and print out what classes are in the archive? I'm using 1.31. Thanks, Keith

2 1

RE: [boost] Re: Re: Logging Library -- Formal Review Request
by Roman Yakovenko 05 May '05

05 May '05

> From: John Torjo [mailto:john.lists@torjo.com] > I really don't understand why you'd want this. And more to the point, > I'm really curious how you could implement this in C++: > > // show what you want above. > BOOST_LOG(app) << "result of f() " << f(); > > And finally, I don't know why you'd want the above. What if f() then > calls g(), and so on, all this functions doing some logging. > Would you actually prefer: > > a.cpp:14: result of f() > [100 lines of other logged messages] > a.cpp:14: 1234 > > To: > > [100 lines of other logged messages] > a.cpp:14: result of f(): 1234 > > Best, > John I'd like to add use case. I think that log messages should be written as soon as possible. Use case: program crash only on specific machine that you can't debug on. If logs messages will not be written immediately they will be lost. In this case this logger is pretty useless. I think that if someone prefer to see > a.cpp:14: result of f() > [100 lines of other logged messages] > a.cpp:14: 1234 he should wrote "log viewer" that will handle this. Roman

4 8

Singleton Review: GCC compiler errors
by Tom Brinkman 05 May '05

05 May '05

Was the "singleton" library tested on GCC. I'm getting many compiler errors on 3.34.

2 1

[std][ptr_container][multi_index] proposal about std algorithms based on iter_swap
by JOAQUIN LOPEZ MU?Z 05 May '05

05 May '05

Hello, although this is more of a std issue than a Boost one, I think it has some nice implications for some Boost libraries, so please allow me to post it here (also, my original proposal at comp.std.c++, http://tinyurl.com/7wjyl, got almost zero response.) The proposed resolution N1523 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1523.htm aims at settling down the issue of whether some std algorithms are required/allowed to call user-provided overloads of swap(): by requiring that internall calls to swap are unqualified, a whole range of algorithms (swap_ranges, reverse, rotate, etc.) are automatically extended to cover types modeling the "swappable" concept: this includes assignable types but also non-assignable types for which a suitable swap() overload is provided. Now, my proposal tries to extend the applicability of these algorithms by adding an extra level of indirection: instead of requiring that swap() is unqualifiedly called, let us mandate that swapping be performed by an unqualified call to iter_swap(). Also, make the definition of std::iter_swap() unqualifiyingly call swap(). What does this buy us? In the general case, the situation is exactly the same as proposed in N1523, but the extra level of indirection allows us to overload iter_swap() in cases where the pointed-to types are not even swappable. A paradigmatic case of use is Boost.PtrContainer: the types held in this kind of containers are in general not swappable, but an iter_swap() overload than simply exchanges the internal pointers makes a lot of sense: the overall result is that rotate, reverse, etc. will work as expected, save the minor detail that this "extended swap" concept does not work as usual with raw pointers to the ext-swapped elements --only iterators to the elements get their pointed-to elements interchanged. What do you think of this? IMHO this can solve the problem of making std swapping algorithms work with ptr_containers, a problem for which (if I'm not wrong) no satisfying solution has been designed. My selfish interest in this proposal stems from the fact that a vector-like type of indices I'm designing for Boost.MultiIndex would also benefit from this. If the idea is well accepted, maybe we can provide Boost implementations of these algorithms taking proper care of unqualifyingly call iter_swap(). Ideas, comments etc. are most welcome. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

RE: [boost] Critique of Boost.Threads
by Brian Braatz 05 May '05

05 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Aaron W. LaFramboise > > Of Aaron W. LaFramboise Wrote: > > > I've been thinking about Dave Abraham's suggestion > <http://lists.boost.org/boost/2005/03/21839.php> that theres no reason > to provide a special protection mechanism for these inner handles. The > feeling I get from many here is that you should be able to hit a red > button, such as including a special implementation header, and you're > back in shoot-yourself-in-the-foot land, with the confidence that "the > programmer knows what he's doing." > > I've decided that this is not compelling for me. We always know what > we're doing--we're superheroes, we're C++ programmers. Yet C++ is > partly about letting us define a set of rules for ourselves, to catch > our mistakes, and keep us honest. I think the ability to hit this red > button and suddenly have full license to blow away a class's invariants > without any of the traditional protection mechanisms is downright > barbaric. > > I think there *is* something special about inheritance. The "protected" > keyword gets wonderful milage in other application domains, and I have > no idea why system abstractions need to be any different, such that for > system dependence, its perfectly acceptable to revert to > pre-Dijkstraesque programming practices. Certainly noone would tolerate > this additude with other well-defined standard libraries: no matter how > much you beg, you just aren't going to get anyone to give you a pointer > to std::list's linked list head. [Brian Braatz Writes:] Weighing in. I am IN agreement with DaveA in the following "> David Abrahams wrote: > >> I have always thought that concrete implementations of portable >> libraries should supply users a way to get at the OS-specific data so >> they can use platform-specific facilities on them if neccessary. >" One of the problems of standardization of interface is that it HAS TO BE expandable and allow for future work to be piled on top of it. In this case the best analogy I can provide is Microsoft Foundation Classes. Yes, yes, YES. I know it is evil in it's design. But one thing they was make it EASY for you to use "their" abstractions, but at the same time, allow for the programmer to decide they need to use a special API call. MFC is evil in many ways, but it has lasted a VERY long time and there are many applications written with it. I personally believe this is largely due to the notion that they ALLOW me to get to the underlying handle. This way, when the OS gets the ability to allow me to BLT semi-transparent gradient images, I can USE this in MFC, even though they never designed this model into it. While It is easy to argue MFC is mentally deficient in its design, I believe this one trait has given it utility and longevity. With THREADING- I believe the following: Moore's law is dead. Multi-core is where the HW folks are headed. The OS vendors, will naturally begin to add more API functions giving me more bells and whistles to play with in the threading world. Without access to the underlying handle, a threading library will not be quite as useful in "the real world" where I MIGHT need to take the plunge and hook up to some OS specific (or HW specific) concept. We must think about threading (and many other types of standard interfaces) as the FOUNDATION of further thinking. NOT the "final" design in the domain. :)

1 0

Singleton Review: global variables
by Tom Brinkman 05 May '05

05 May '05

In the singleton documentation it states that "singletons" could/should replace all global variables in an application. Does this comment apply to global vectors as well. I have a vector of boost::any which I've declared static in a resource class. <code below> struct resource { static std::vector<boost::any> resources; ...<more>... }; std::vector<boost::any> resource::resouces; How would one incorporate this global vector into the singleton library to take advantage of its facilities.

2 1

Re: [boost] BOOST_FOREACH review results
by brangdon＠cix.compulink.co.uk 05 May '05

05 May '05

In-Reply-To: <d5c6jf$2bm$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > The only two negative reviews based their rejection on principle: > "Macros are evil and so should not be used". While this maybe > interesting point in itself, as I see things now, boost practice > supports using macros where necessary and macro nature of the tool > could not be a compelling enough reason to reject the submission. For the record, my review was negative and was not based on that principle. I agree with the boost policy of using macros where necessary. I rejected it because it is an overly complex solution to a simple non-problem. > While there were not so many specific issues discovered during > review, I would like to list couple: What about the name? Shouldn't it be "BOOST_FOR_EACH"? -- Dave Harris, Nottingham, UK.

5 4

RE: [boost] Re: [threads] Future directions (Was: TR2 and C++0x headsup)
by Cronje, Schalk 05 May '05

05 May '05

-----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrei Alexandrescu (See Website >I think I'd be representing the opinion of the entire group by saying >that a library-only approach is naive at best. See for example "Threads >Cannot Be Implemented As A Library" by Hans Boehm at >http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf, paper admitted >at the prestigious conference PLDI 2005 (sign that others believe Hans >actually makes sense). Actually I believe that any expert in threading >would cringe at the thought that Boost.Threads made it in the C++ standard. You definitely speak for me here. I would not like to see it go in as part of C++0x. >Speaking for myself about the quality of Boost.Threads' design itself, I >would add that it compares unfavorably (to use an euphemism) with many >other threading library interface for C++ or other languages - actually >all I know of, including unpublicized ad-hoc threading libraries >developed in-house at various companies I've worked with. I am much more in favour of a generic decoupled approach such as what Kevlin Henney has suggested (http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.p df). This approach lends itself to even more generic abstractions such as asynchronous functions as presented at Accu2005.

1 0

Review Schedule (5-May-2005)
by Tom Brinkman 05 May '05

05 May '05

The FOREACH macro has been accepted in to boost. The "singleton" library review starts today 5-May-2005. If you haven't done so already, download the library at http://tinyurl.com/6qvrd and submit a review by 15-May-2005. Review Queue as of May 5, 2005 1) Singleton (5-May-2005; Ends: 15-May-2005) 2) Typeof (Starts: 20-May-2005; Ends: 30-May-2005) 3) Function Types (To be confirmed: 5-June-2005; Ends: 15-June-2005) 4) Logging 5) Policy Pointer Possible Future Reviews: 6) Fixed Strings 7) Intrusive (Review Manager Needed) 8) TR1 (Review Manager Needed) 9) Fusion 10) Factory 1) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com peder.holt(a)gmail.com Review Manager: Andy Little andy(a)servocomm.freeserve.co.uk Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: John Maddock john(a)johnmaddock.co.uk Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 4) Logging Library Author: John Torjo john.lists(a)torjo.com Review Manaer: Hartmut Kaiser hartmut.kaiser(a)gmail.com Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 5) Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. 6) Fixed Strings Author: Reece Dunn msclrhd(a)hotmail.com Review Manager: Beman Dawes bdawes(a)acm.org Available At: boosts-sandbox/boost/fixed_string The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. 7)Intrusive Author: Olaf Krzikalla krzikalla(a)gmx.de Review Manager: Needed Available At: http://people.freenet.de/turtle++/intrusive.zip Library presenting some intrusive containers to the world of C++. While intrusive containers were and are widely used in C, they became more and more forgotten in the C++-world due to the presence of the standard containers, which don't support intrusive techniques. Boost.Intrusive not only reintroduces this technique to C++, but also encapsulates the implementation in STL-like interfaces. Hence anyone familiar with standard containers can use intrusive containers with ease. 8) TR1 9) Fusion 10) Factory Author: Federico Stella f.stella(a)flashnet.it

1 0

Boost filesystem documentation
by James Gregory 05 May '05

05 May '05

http://www.boost.org/libs/filesystem/doc/exception.htm begins by saying: "The header provides class filesystem_error, publicly derived from std::runtime_error" I think this is wrong, isn't it publically derived from std::exception? Thanks, James

2 1

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 05 May '05

05 May '05

In-Reply-To: <4277C3E9.60407(a)boost-consulting.com> eric(a)boost-consulting.com (Eric Niebler) wrote (abridged): > Is do/while an algorithm? for (iterator i = c.begin(); i != c.end(); ++i) is an algorithm. Do/while would be if it included the code to step through a container. > You probably don't think of it that way. It's certainly not an > algorithm in the STL sense like std::for_each is. Again, a for-loop is. > The most effective way to think of BOOST_FOREACH (in my experience) > is as a new looping construct -- a foreach keyword. It's not a keyword. It's a macro which encapsulates an algorithm - roughly the same algorithm as std::for_each. > To encourage people to think of it as an algorithm in the STL sense > would be a mistake. It is range-based, not iterator-based. An algorithm does not need to be iterator-based to be an algorithm. > You can break and continue and return from the loop body. You can't > do any of those things from an STL algorithm. That's because the STL algorithms encapsulate differently, not because they are not algorithms. In any case, the question of whether FOREACH is an algorithm is a red herring, because the use of underlines as word separators does not just apply to algorithms. It also applies to macros (eg "BOOST_STATIC_ASSERT") and keywords (eg "static_cast"). Although there are some C++ keywords that don't have underlines, eg "sizeof", these are mostly inherited from C. The modern trend is for underlines unless there is a compelling reason otherwise. You've not offered a compelling reason. It sounds like you are mimicking the "foreach" of some other language. I think a C++ library should use C++ conventions, not the conventions of whatever it is you are copying. Consistency is important. Also, program text is easier to read if words don't all run together. -- Dave Harris, Nottingham, UK.

3 2

BOOST_FOREACH review results
by Gennadiy Rozental 05 May '05

05 May '05

Hi, everybody BOOST_FOREACH macro by Eric Niebler is accepted into boost. The library was received pretty good by boost community (I counted at least 13 positive reviews). The only two negative reviews based their rejection on principle: "Macros are evil and so should not be used". While this maybe interesting point in itself, as I see things now, boost practice supports using macros where necessary and macro nature of the tool could not be a compelling enough reason to reject the submission. Would this trend be ever changed in a future we could change a policy for future submissions. While there were not so many specific issues discovered during review, I would like to list couple: * documentation should contain more examples and special pitfalls section * testing should be split by compatibility sections * it would be good to make this facility work on more compilers Congratulation Eric for the excellent work and thanks to all the reviewers for participation. Gennadiy Rozental BOOST_FOREACH review manager

5 5

[bug] using boost::range and boost::array in MSVC 6.0
by Joe Gottman 05 May '05

05 May '05

MSVC 6.0 gives an internal compiler error when I include the following headers in the order below: #include <boost/array.hpp> #include <boost/range.hpp> The reason for this ICE (besides MSVC 6.0 being a non-conformant compiler) is the fact that several files in the boost/range/ subdirectory declare functions having a parameter called "array". It seems that MSVC has problems realizing that this is the name of a new variable, not an already existing class. When I renamed these parameters everything compiled fine. Would it be possible to change these parameters to a name that isn't the name of a boost class, something like c_array maybe? Thank you, Joe Gottman

2 1

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 05 May '05

05 May '05

In-Reply-To: <ufyx36ixl.fsf(a)boost-consulting.com> dave(a)boost-consulting.com (David Abrahams) wrote (abridged): > >> * This isn't an algorithm, so I don't want to evoke std::for_each. > > > > What is it that makes std::for_each an algorithm and BOOST_FOREACH > > not? > > You might consider just answering the first part of that question for > yourself: "what is it that makes std::for_each an algorithm?" It's a finite series of well-defined steps. As is BOOST_FOREACH. In any case, we use underlines in keywords and macros, too. For example, "dynamic_cast" or "BOOST_STATIC_ASSERT". -- Dave Harris, Nottingham, UK.

1 0