- Boost - lists.boost.org

[filesystem] typo in doc/operations.htm
by Caleb Epstein 28 Dec '05

28 Dec '05

On the page http://boost.org/libs/filesystem/doc/operations.htm, in the "rename" section: "Note: Some operating systems with multiple roots<http://boost.org/libs/filesystem/doc/index.htm#multi-root_filesystem>do not allow *rename* operations between roots, and such an attempted *rename* with throw a * filesystem_error <http://boost.org/libs/filesystem/doc/exception.htm>*exception.." Should read: * *"Note: Some operating systems with multiple roots<http://boost.org/libs/filesystem/doc/index.htm#multi-root_filesystem>do not allow *rename* operations between roots, and such an attempted *rename* will throw a * filesystem_error <http://boost.org/libs/filesystem/doc/exception.htm>*exception." E.g. change "with" to "will". Note also that there is an extra period at the end of the sentence. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[Boost-bugs] [ boost-Support Requests-1391956 ] Embedded python won't compile
by SourceForge.net 28 Dec '05

28 Dec '05

Support Requests item #1391956, was opened at 2005-12-28 05:15 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=1391956&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: Embedded python won't compile Initial Comment: I followed the tutorial about embedding at http://www.boost.org/libs/python/doc/tutorial/doc/html/python/embedding.htm… but I am now faced with some errors (VC++ 6.0, latest Service Pack running on Windows 2000 SP4). The errors: Compiling... StdAfx.cpp Compiling... pytest.cpp f:\pytest\pytest.cpp(10) : error C2065: 'object' : undeclared identifier f:\pytest\pytest.cpp(10) : error C2146: syntax error : missing ';' before identifier 'main_module' f:\pytest\pytest.cpp(10) : error C2065: 'main_module' : undeclared identifier f:\pytest\pytest.cpp(11) : error C2065: 'handle' : undeclared identifier f:\pytest\pytest.cpp(11) : error C2059: syntax error : '>' f:\pytest\pytest.cpp(13) : error C2146: syntax error : missing ';' before identifier 'main_namespace' f:\pytest\pytest.cpp(13) : error C2065: 'main_namespace' : undeclared identifier f:\pytest\pytest.cpp(13) : error C2228: left of '.attr' must have class/struct/union type f:\pytest\pytest.cpp(15) : error C2059: syntax error : '>' Error executing cl.exe. pytest.exe - 9 error(s), 0 warning(s) The code: pytest.cpp ========== // pytest.cpp : Defines the entry point for the console application. // #include "stdafx.h" int main(int argc, char* argv[]) { Py_Initialize(); object main_module(( handle<>(borrowed(PyImport_AddModule("__main__"))))); object main_namespace = main_module.attr("__dict__"); handle<> ignored((PyRun_String( "hello = file('hello.txt', 'w')\n" "hello.write('Hello world!')\n" "hello.close()" , Py_file_input , main_namespace.ptr() , main_namespace.ptr()) )); Py_Finalize(); return 0; } StdAfx.cpp ========== // stdafx.cpp : source file that includes just the standard includes // pytest.pch will be the pre-compiled header // stdafx.obj will contain the pre-compiled type information #include "stdafx.h" // TODO: reference any additional headers you need in STDAFX.H // and not in this file StdAfx.h ======== // stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // are changed infrequently // #if !defined(AFX_STDAFX_H__14167E34_D56C_4B80_BB18_4CB7F7E8E058__INCLUDED_) #define AFX_STDAFX_H__14167E34_D56C_4B80_BB18_4CB7F7E8E058__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers #include <stdio.h> #include "boost\python.hpp" using namespace std; // TODO: reference additional headers your program requires here //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_STDAFX_H__14167E34_D56C_4B80_BB18_4CB7F7E8E058__INCLUDED_) Libs ==== kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib python24.lib boost_python.lib Please help, I would VERY much appreciate it- good job with all the hard work on Boost.Python! My email address is jamclx(a)gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1391956&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[asio] what happens to outstanding operations when demuxer::interrupt called?
by Andrew Schweitzer 28 Dec '05

28 Dec '05

The doc seems to imply that if demuxer::reset() and demuxer::run() are called again, then outstanding operations will in fact be executed. Is this true? Are there general design philosophies out there for handling things that happen way too late because the loop was paused? One system I worked on just fired all the stale timers at once, which I think what asio does. In the system I worked on, no effort was made to check whether the timer was firing hours too late. Would it be reasonable to modify the timer completion handler to accept the amount of time "overdue" the current call of the handler is? This would at least allow the handler to check, but maybe that's too complicated. There appears to be no general way to toss all work outstanding, is this correct? I assume that's because it's hard to do so portably for all services. On the other hand, it seems like maybe just deleting all your deadline_timer or stream_socket objects would cause them all to be cleaned up.

2 1

[boost.test] Non-conforming operator new, AFAICT
by Markus Schöpflin 28 Dec '05

28 Dec '05

Hello, boost.test currently contains an assortment of new operators which IMO are not conforming to the C++ std. The implementation basically looks like this: p = std::malloc(n); if (!p) throw std::bad_alloc(); This ignores the fact the std::malloc() is allowed to return either 0 or some unique pointer on zero sized requests, whereas a C++ allocation function _must_ return a unique pointer for each zero sized request. If I'm correct, this could be easily fixed by changing all occurences of "p = std::malloc(n)" to "p = std::malloc(n ? n : 1)" or something similar. Regards, Markus

4 8

[Boost-bugs] [ boost-Bugs-1391875 ] _GLIBCXX_DEBUG fails on 1.33.1 - bug or design?
by SourceForge.net 28 Dec '05

28 Dec '05

Bugs item #1391875, was opened at 2005-12-28 12:02 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=1391875&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: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rafal Wijata (ravpl) Assigned to: John Maddock (johnmaddock) Summary: _GLIBCXX_DEBUG fails on 1.33.1 - bug or design? Initial Comment: Results in segfault (on vector destructor) Was ok(and still is) on 1.33.0 Compiled with gcc 4.0.2 on RHELAS4 with g++ -rdynamic -export-dynamic -D_GLIBCXX_DEBUG -g -lboost_regex -o test test.cpp sourcefile incuded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1391875&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[variant] Proposal for compile time checked getter
by Zara 28 Dec '05

28 Dec '05

Dear all, During a redesign, I began using boost::variant, and I detected that trying to get a value of a type not included in variant type-list resulted in run-time error (cast or null pointer). I feel that a variant should only try to return a valid type from its type-list, otherwise giving a compiler error, and reserve runttime errors for that case when someone tries to get a value from a type contained in the typelist, but not the actual type contained in the actual object. In such a way, I have made a little redesign on boost::get and called it boost::checked_get: namespace boost { template <typename U, BOOST_VARIANT_ENUM_PARAMS(typename T) > inline typename add_pointer<U>::type checked_get( boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) >* operand BOOST_VARIANT_AUX_GET_EXPLICIT_TEMPLATE_TYPE(U) ) { typedef boost::variant< BOOST_VARIANT_ENUM_PARAMS(T) > Variant; /* throw a compile-time error if type is not contained on type list */ BOOST_STATIC_ASSERT((!is_same< typename mpl::find<typename Variant::types,U>::type, typename mpl::end<typename Variant::types>::type>::value)); typedef typename add_pointer<U>::type U_ptr; if (!operand) return static_cast<U_ptr>(0); detail::variant::get_visitor<U> v; return operand->apply_visitor(v); } } // end of addition to namespace boost And, of course, the rest of the templates needed for const *, ref and const&.. I think it would be interesting to include it in boost libraries. In fact, I use it intensely. Best regards, -- Zara PS Forgive me for my bad english.

1 0

[asio] Why "const mutable_buffers &" in interfaces?
by Mats Nilsson 28 Dec '05

28 Dec '05

Hi Just a question asking to clarify the use of "const Mutable_Buffers &mutable_buffers" in the calls to some of the functions, e.g stream_socket::receive(const Mutable_Buffers &buffers, message_flags flags). To me, this is not logical, since I'd expect a receive function to actually modify the stuff I send into it, and the const qualifier doesn't seem to allow this. If it needs to be this way, you might want to explicitly explain this design choice somewhere close to where it is used. Also the reference documentation for asio::mutable_buffer seems to have a copy-paste bug; its detailed description includes "The const_buffer class provides ...", or am I missing something? Mats

3 2

Some Boost.Test queries
by Daryle Walker 27 Dec '05

27 Dec '05

1. Is there a way to specify that two auto-unit tests must come in a certain order? What about any kind of tests? Or do you have to create a giant test to force a particular order? 2. If the answer to [1] is "yes," then can fixtures be used to carry over changed variables between tests? 3. Can a fixture be a class template, so it can be used with a auto-unit test template such that the fixture changes its class parameter to match the test's parameter? (I worked around this currently by using an inner class template within a non-template class fixture.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[defer] - new version uploaded
by simon meiklejohn 26 Dec '05

26 Dec '05

New version of the Defer library uploaded to the Boost Vault, Concurrent Programming folder. Main addition is support for a size configurable work item queue provided by Oliver Kowalke (thanks Oliver), from the thread_queue component in the same folder. This library may provide a counterpoint to the Boost.Asio library's related work deferral facilities. Cheers Simon

1 0

Re: [boost] [Review] Boost.Logging: formal review
by Richard Glanmark 26 Dec '05

26 Dec '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennadiy Rozental > Sent: den 15 december 2005 22:39 > To: boost(a)lists.boost.org > Subject: Re: [boost] [Review] Boost.Logging: formal review > > > 1. Enabled/disabled logger, logging macros and efficiency > > > > The logging macro BOOST_LOG should accept two arguments > instead of one. > > The logger and the log message. The syntax > > > > (1) BOOST_LOG(some_log) << "my message " << foo() << bar(); > > > > should be replaced with > > > > (2) BOOST_LOG(some_log, "my message " << foo() << bar()); > > > > and the macro being defined something like this > > > > (3) #define BOOST_LOG(logger, msg) \ > > if(logger.isEnabled()) { /* code that logs msg */ ... } > > > > Thus, disabled loggers will never take longer than simple > > if-statement, as long as the isEnabled() method is fast, which IMO > > should take no longer than comparing booleans. > > 1. I think this is also the case in original interface. > > > In the original solution (1) the method foo() will always > be called, > > which is inefficient when the logger is disabled, in solution (2), > > foo() will never be called when the logger is disabled. > > I think you are mistaken Yes, my mistake. > > Further more, the macro could insert extra information such as > > __LINE__, __FILE__ etc. > > This is also true for original interface. Yes true -- my mistake again (I didn't look enough at the implementation of the macro). > All in all I prefer message not be inside brackets. It looks > much more natural and I don't see any theoretical problens to > get the same performance. But I also believe that macro > shouldn't be a primary interface. > So if you prefer message inside the breakets - it's your choice. However, there is one additional benefit of placing the message inside brackets. One can remove the log statement in a build. Other than that, I guess its style preferences. > > 2. Filtering > > > > There has been some discussion about the ability of a library to be > > able to do more filtering than simple log levels, notably > by Gennadiy > > Rozental. > > > > Gennadiy writes: > >> At the bare minimum it should support: > >> > >> entry level - levels set is ordered set of values indication > > importance of > >> information provided. Filtering is based on threshold. Examples: > > DEBUG, INFO, MAJOR > > > >> entry category - categories set is a set of unique values > indicating > > kind of > >> information provided Filtering is based on masking. > >> Examples: ARGS, RETURN_VALUE, ERROR_LOG, DATA_FLOW, PROG_FLOW > > > >> entry keyword - keyword set is set of user defined keywords (most > > frequently strings) > >> identifying area of the program. Filtering is based on match of > > keywords. > >> Keywords usually are used to mark specific part of application. > > > > I agree that it is very important for a logging library to > support this. > > However, I do not think that the solution is for the > logging library > > to be aware of such special values. The library should be as > > simplistic as > > My position that library should be configurable by any class > satisfying Filter concept. > This particular filters could probably be supplied by the > library as an example and as most widely useful. > > > My proposed solution is to basically let loggers be somewhat entry > > (Gennadiy's definition above) unaware. Instead, let the developer be > > I do not see how it's possible. IMO framework should employ > some MPL magic and construct proper entry structure based on > set of Filters passed as template policy parameters. > > > entry aware. By that I mean that the developer should log messages > > that belong to a specific entry category/level to a > specific logger. > > For > > This is never be acceptable IMO. Even with 3 filters, each > ahving 5 possible values you looking into 125 different loggers. Support for log functions on top of a basic framework solution is needed to alleviate this problem. I wouldn't mind that the library provides log funtions that take various filter functions or predicates to determine wether to send a log statement to a logger. In this case, the logger would be enabled and the log filter function would send log statements to the logger if the log statement meets some criteria. Still, the underlying logger framework would be the same; logger object should still be enabled or disabled/enabled, there would still be a few different logger objects for different levels and possible other user defined criteria. IMO it is very important for an administrator/programmer of a system to be able to enable/disable logs, know what loggers and appenders exists and be able to configure said entities. If filter is only done on a per log statement, how do you even know as a administrator of a system what log filters exists? Which filter criteria should be enabled and which filter criteria should be disabled? If all log statements are sent to one logger object, the logger object becomes a monolith of functionality and complexity. Runtime performance might degrade considerable if various filters is to be checked, not only if the log statements should be logged, but also if one wants to send log statements to different appenders/sinks/destinations. Cheers, Richard The content of this e-mail is intended only for the confidential use of the person(s) to whom it is addressed. If the reader of this message is not such a person, you are hereby notified that you have received this communication in error and that reading it, copying it, or in any way disseminating its content to any other person, is strictly prohibited. If you have received this message in error, please notify the author by replying to the e-mail immediately. NeoNet AB and its subsidiaries (NeoNet Securities AB, NeoNet Securities Inc. and NeoNet Technology AB) are unable to exercise control over the content of information contained in transmissions made via the Internet and hereby excludes any warranty as to the quality or accuracy of any information contained in this message and any liability of any kind for the information contained in it, or for its transmission, reception, storage or use in any way whatsoever.

7 8