August 2005 - Boost - lists.preview.boost.org

[range] extension proposal - construct
by Pavol Droba 22 Aug '05

22 Aug '05

Hi, I have a proposal for addition to Boost.Range library: template<typename RangeT, typename OtherRangeT> RangeT construct<RangeT>(const OtherRangeT& Source); template<typename RangeT, typename IteratorT> RangeT construct<RangeT>(IteratorT From, IteratorT To); Both functions should construct a range of type RangeT, that will contain elements from Source or [From,To) respectively. Motivation: In the standard library Sequence concept defines a way for constructing a sequence from and arbitrary range of iterators. This is very useful concept and it would be nice to have something similar available in the Range library. Most significant advantage of this construct is that it allows to create algorithms, that modify an input range and return a copy of it. Currently there is no generic way for constructing or modifying a range, therefor it restricts the usage of range to non-mutable input parameters. For instance a simple to_lower algorithm (available in StringAlgo library) template<typename SequenceT> SequenceT to_lower_copy(const SequenceT& Input, const std::locale& Loc=std::locale()); requires the input to satisfy sequence requirements so it can construct the result. This effectively disables many advantages of Range library. Because it is not possible to adapt an external class (like CString) to work with this algorithm. Yes it could be very easy to implement construction for this class. There is already a similar function in the range library. It's called copy<> but, this function is provided solely for sequences and there is no feasible and documented way for customization. Best Regards, Pavol

3 3

logging v1.4 - some comments
by Darryl Green 22 Aug '05

22 Aug '05

Excuse the break in threading - gmane has lost/missed a lot of boost traffic. Hi John, I've only had a quick look at the latest version: The m_destroyed hack needs to go - this should only be relevant for static (not scoped) logs and the real issue is that you need to do thread-safe singletons - ie. you need to use posix call_once or equivalent to contstruct the thing. Destruction is a bit tricky - not doing it seems a reasonable option, though stopping leak detectors from compaining would be nice. The scoped log stuff doesn't seem to have been updated to support levels yet - in fact I'm not sure if it currently works? I think (fancy that - given the way it was in analog ;-)) that the named appenders need to be managed - currently, you can create multiple appenders with the same name, then when you delete by name you delete all appenders with that name. I don't see the utility of that model, which when combined with the wildcard matching is really fairly hard to use. For example, suppose I have an appender that logs to some sort of display for "real time" tracing. First off, I say: manipulate_logs("error.*").add_appender(displaywrite, "display") Then I notice an error about some component foo and decide to look at more detail about foo: manipulate_logs("*.foo").add_appender(displaywrite, "display") Now I get anything logged to "error.foo" written to "display" twice. I then say: manipulate_logs("error.*").del_appender("display") Because I want to concentrate on "foo" only. Now I find I don't get errors from foo displayed, only other less critical messaages. Then, foo goes out of scope (it's a scoped log), only to come back into scope again. When it does, and it generates an error, I'm (not really) suprised to see it sent to "display".... As the purpose of named appenders is to facilitate runtime modification of the appender set, surely the ability to make these modifications using *only* the name is reasonable. The fact that add requires a function while del only needs a name only highlights this. Regardless of what the rules for combining appenders/modifiers/enabledness are, they need to be consistent and to work across scoped logs going in/out of scope. I think what is needed is a set of connections (logs connect to appenders/modifiers) ordered by the log name which may include wildcards. Log name (segments) containing wildcards should be ordered before exact names so the more specific rules override the less specific ones. Note the above was from reading the docs + code - I haven't tried running it yet, and maybe I'm misunderstanding something. Regards Darryl.

6 9

logging v1.4 - multiple levels implemented!
by John Torjo 22 Aug '05

22 Aug '05

Hi all, Just updated the Logging library. Find it here: http://torjo.com/code/logging.zip Also, I've updated the docs. Feedback is welcome. Highlights: **** Multiple levels. **** Easier manipulation of logs **** Modifiers/Appenders can now be deleted. **** Shortcut for BOOST_IS_LOG_ENABLED **** Exception guards **** Shared Memory Appender **** Multiple levels. You can specify levels, very much like log4j. To assign a level to a message, use BOOST_LOGL, like this: BOOST_LOGL(app,dbg) << "some debug message"; BOOST_LOGL(app,err) << "some error"; BOOST_LOGL(gui,warn) << "some GUIsh warning"; Note the BOOST_LOG still works: BOOST_LOG(app) << "some message"; // equivalent to: // BOOST_LOGL(app,default_) << "some message" **** Easier manipulation of logs Every time you need to manipulate some logs (add/delete appenders/modifiers, set the log's level), you use manipulate_logs("logs_spec") Example: manipulate_logs("*") // all logs prefix the message by time .add_modifier(prepend_time("$hh:$mm:$ss "), DEFAULT_INDEX + 1 ) // all log' messages are prefixed by the log name .add_modifier(&prepend_prefix) // all messages are written to cout .add_appender(&write_to_cout); // write all dbg messages and above to app.* logs manipulate_logs("app.*").enable(boost::logging::level::dbg); **** Modifiers/Appenders can now be deleted. In order to delete a modifier/appender, just give it a name: // prepend time, and name this modifier as "time" manipulate_logs("*") .add_modifier(prepend_time("$hh:$mm:$ss "), "time" ); // at a later time BOOST_LOG(app) << "this is prefixed by time"; manipulate_logs("*") .del_modifier("time"); BOOST_LOG(app) << "this is NOT prefixed by time"; ***** Shortcut for BOOST_IS_LOG_ENABLED Instead of saying: // test if message should be written to this log if ( BOOST_IS_LOG_ENABLED(app,some_level)) ...; You can say: if ( app()(some_level)) ...; **** Exception guards When logging, if any modifier/appender throws, the exception is not allowed to propagate. **** Shared Memory Appender An appender that allows writing to a shared memory zone, internally using shmem library. Still to do: **** compile-time logs: write docs about it **** appenders to Event log **** alternate logging manager 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!

5 15

Boost regression notification (2005-08-22)
by Douglas Gregor 22 Aug '05

22 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-22T15:05:38Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 65 failures in 6 libraries: functional/hash (9) graph (9) parameter (4) python (22) serialization (20) wave (1) |functional/hash| books: vc-6_5 vc-6_5-stlport vc-7_0 point: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 portable: vc-6_5 vc-6_5-stlport |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Start separating mandatory source?
by Daryle Walker 22 Aug '05

22 Aug '05

Since we just had a release, should be re-visit moving all the mandatory source code into a separate directory together? For the newbies, this means changing the BOOST_ROOT . libs .. date_time ... src .. graph ... src into something like BOOST_ROOT . src .. date_time .. graph Right now, using mandatory source files means scrambling into a lot of directories figuring out what to add. There is stuff like Boost-Build, but it doesn't work for everyone, and I feel that it's a "cute" overkill solution. No matter the plan there are some caveats: 1. Some platforms require some libraries to be put in separate DLLs. 2. You have to exclude the driver files from Boost-Test, since each includes a "main" function. (And if you actually are doing testing, then you know that you can include at most one driver file.) Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build. If some source needs to be in a DLL, then start a sub-project. (If you don't need a library at all, then exclude it from the project to save compile time. The linker will tell you, by choking, if you went too far.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Should we add two simple character-to-Unicode converters?
by Daryle Walker 22 Aug '05

22 Aug '05

Nothing fancy, just something like: int_fast32_t char_to_Unicode( char c ); int_fast32_t wchar_to_Unicode( wchar_t c ); that converts a native character to a Unicode value. They would need a separate source file that contains #if blocks for each platform. Maybe they can start a namespace with "utf8_codecvt_facet"? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 3

interest in "policy_composite" library?
by Larry Evans 22 Aug '05

22 Aug '05

Is there any interest in a "policy_composite" library which will have policies just as the proposed policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… library has policies? These composite policies might allow different allocation strategies for variant and possibly different CTOR arguments for tuple. It could also allow adding different methods, such as the get_base_ptr(void) as described here: http://groups-beta.google.com/group/comp.std.c++/msg/27e41e693228c6c7?hl=en& which would of course satisfy (hopefully) that OP's request for a variant extension.

1 0

Re: [boost] Should we add two simple character-to-Unicode converters?
by Graham 22 Aug '05

22 Aug '05

>From: Daryle Walker <darylew(a)hotmail.com> Dear Daryle, >I thought of these functions while considering how Wave process the various >phases of C++ translation (see section 2.1 of the standard). I wanted the >conversion to be one native-character to one code-point because that is how >Phase 1 implies it[1]. If you don't think that's right, maybe we should >file a defect with the Standard committee. Maybe I misunderstood you - you seem to be asking for code page conversion here not UTF conversion. Code page conversion is anything but simple and requires data conversion tables for many of the code pages. It is not very practical at the character level as you can see from the calls below, but would require conversion objects to be created that can then implement these functions. int_fast32_t char_to_Unicode(std::string locale, char c ); // very inefficient int_fast32_t wchar_to_Unicode(std::string locale, wchar_t c ); // very inefficient conv1250 = new convertor(std::string locale); // better convertor->char_to_Unicode(char c); >[1] In other words, any extended native character (i.e. not a character C++ >uses for parsing) must be mapped to one C++ Unicode name, which maps to a >single code-point. That depends on what you mean. For example <e><acute> can be one <e acute>, or two <e><acute> Unicode characters depending on how it is normalised. A character parser should understand this if it wants to present Unicode graphemes which are the default unit of parsing in unicode and which should be in any compliant native handler even if working with the local code page. I suggest you wait for the release of the unicode library, alternatively if you want to volunteer to write lots of code page conversion functions, and their data tables where necessary, please let us know. Yours, Graham

2 1

Updated version history
by Daryle Walker 22 Aug '05

22 Aug '05

I added items for 1.11.1 and 1.11.0, which I found in e-mails in the Archives. Worse, 1.11.1 was just incidentally mentioned and was not a subject of an e-mail. Updated CVS and the web site (hopefully not frying the latter). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[config] Why does BOOST_NO_INTEGRAL_INT64_T depend on BOOST_HAS_LONG_LONG?
by Markus Schöpflin 22 Aug '05

22 Aug '05

Currently config/suffix.hpp contains the following code which seems pretty wrong to me: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode. Shouldn't these lines just be removed? Markus

3 10