- Boost - lists.boost.org

Proposal: Addition to boost::integer_traits
by Jeffrey C. Jacobs 04 Jul '04

04 Jul '04

A while ago I proposed adding a signed_traits class and then after receiving some input decided it better this be a property of some existing traits object, ideally "integer_traits" since only integer can be signed. I tried to contact some people to whom I'd been referred about changing integer_traits.hpp but never heard back. Otherwise I have received no negative feedback from this proposal. The idea is simple, as with the min and max constants associated with boost::integer_traits, there would be: boost::integer_traits<x>::unsigned_type boost::integer_traits<x>::signed_type I also proposed a boost::integer_traits<x>::type But that would be x and so wouldn't be very useful. With these additions, one would be able to get the signed or unsigned form of a type without knowing the type detail. In other words, one can apply "signed" or "unsigned" to any specialized integral type that supports it. (Obviously bool would not be supported, nor would any non-integral types.) OTOH, a user-defined pseudo-integral type could provide its own specialization which would be a way of converting between signed and unsigned Abstract Integral Types (AITs) in a generic way: template <> class integer_traits<my_signed_type> : public std::numeric_limits<my_signed_type>, public detail::signed_integer_traits_base<my_signed_type, my_unsigned_type> { BOOST_STATIC_CONSTANT(bool, is_integral = true); }; Note: here I do not use the boost::detail::integer_traits_base helper because my_signed_type does not have a min or max value and even if it did, it is not possible to do in-class initialization with abstract data types. I would also be providing a specialization of std::numeric_limits. Note also because of these orthagonal properties, I provide a separate base class for signed_integer_traits_base, rather than adding to integer_traits_base. The idea would then be to have a new type in the boost::details namespace: template <class ST, class UT> class signed_integer_traits_base { public: typedef ST signed_type; typedef UT unsigned_type; }; And define each integral type correspondingly, e.g.: template<> class integer_traits<bool> : public std::numeric_limits<bool>, public detail::integer_traits_base<bool, false, true>, public detail::signed_integer_traits_base<bool, bool> { }; template<> class integer_traits<char> : public std::numeric_limits<char>, public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX>, public detail::signed_integer_traits_base<signed char, unsigned char> { }; // ... template<> class integer_traits<int> : public std::numeric_limits<int>, public detail::integer_traits_base<int, INT_MIN, INT_MAX>, public detail::signed_integer_traits_base<signed int, unsigned int> { }; template<> class integer_traits<unsigned int> : public std::numeric_limits<unsigned int>, public detail::integer_traits_base<unsigned int, 0, UINT_MAX>, public detail::signed_integer_traits_base<signed int, unsigned int> { }; // ... The one problem with this as I see is cv-qualification. Clearly, this will only provide the cv-unqualified types input as if I read ISOC++ 14.1.5 correctly, and I may not be, the top-level cv-qualification of the integral type template parameter would be dropped. E.g.: boost::integer_traits<const int>::signed_type would be [signed] int, NOT const [signed] int. In general, this is what you want because it saves you from writing specialization for each cv-qualification, but it then looses information about the source type, namely how it was cv-qualified. For the other traits, where static functions or constants are provided, the cv-qualification does not matter; it is only in the manifestation of the typedef that causes this inconvenience. However, I think this approach better than none though suggestions and corrections are welcome. Jeffrey.

3 3

[OT] Whether and how to obfuscate email addresses in posts, docs & code
by Andreas Huber 03 Jul '04

03 Jul '04

Dear Boosters What follows is OT, but since this post discusses a problem that I expect to hit boost contributors especially hard I think it is ok to post it here. If not, please let me know. **** lengthy obfuscation rationale begin **** Spammers routinely harvest email addresses from web pages and newsgroups. Viruses scan harddisks to find email addresses of potential new victims. Spammers have even started to use special viruses to install backdoors on computers and then later hijack the infected machines to send their junk to the email addresses found on the harddisk (see e.g. http://tinyurl.com/35usd) Boost contributors are especially vulnerable as their email address is published on the boost website and on the boost list. Moreover, their email address can be found on the harddisks of the thousands of people who use the boost distribution. Despite these vulnerabilities, very few obfuscate their address on the list and in the 1.31 distribution (I don't do so yet, either). Sure, virus scanners and spam filters alleviate the problem but they can never fully solve it. Spammers have become very sophisticated in making their junk pass filters. Although I'm employing multiple spam/virus filters (spamcop, gmx, yahoo) I'm currently getting about 10 unsolicited messages per day (up from about 3 per day a year ago) and I'm concerned what will happen once my address is stored on thousands of hard drives when/if my library is accepted into boost. Sure, I could simply disable my throw-away address and publish a new one as soon as spam/virus levels become unbearable but that also immediately cuts off users who have downloaded the distribution. Plus, this solves the problem only temporarily. So, the only real solution to considerably reduce email junk is to thwart automatic harvest and thus to obfuscate email addresses. I realize that even this offers no guarantee for not receiving spam/viruses as someone sending me email will often have my unobfuscated email address on his/her hard drive but it definitely reduces the number of locations where my address can be harvested considerably. **** lengthy obfuscation rationale end **** Questions: 1. How do other contributors deal with spam/viruses clogging up their in-boxes? Am I worrying about something that will never be a big deal? 2. What do other people think about a voluntary boost standard for obfuscating email addresses published in posts, docs & code? 3. If you think 2. is a good idea then what is a good way to obfuscate email addresses? Is the simple <at> & <dot> approach sufficient or do we need something that is less common (and thus prone to automation)? E.g. WHATah2003EVER(a)gmx.net with a remark to remove all capital letters? Regards, Andreas

4 7

boost/config/suffix.hpp: spurious BOOST_HAS_THREADS with g++ 3.4
by Christoph Ludwig 03 Jul '04

03 Jul '04

While testing gcc 3.4 (on a x86 PC running Linux), I encountered linker errors due to missing pthread symbols, even though my program is single threaded. I found that some translation units using boost::shared_ptr included boost/detail/lwm_nop.hpp whereas other translation units included boost/detail/lwm_pthreads.hpp. I didn't observe any errors with gcc 3.3.x. The problem turns out to be that gcc 3.4 defines the preprocessor variable _REENTRANT if certain standard library headers are included even if the compiler is *not* called with the '-pthread' command line option. The following test exhibits this behavior and shows that it causes BOOST_HAS_THREADS to be erroneously defined in boost/config/suffix.hpp if, e.g., the standard header string is included: cludwig@lap200:~/C++/gcc3.4/tmp> g++ -v Lese Spezifikationen von /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Konfiguriert mit: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0 --enable-threads=posix --enable-version-specific-runtime-libs --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar --enable-concept-checks --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch Thread-Modell: posix gcc-Version 3.4.0 cludwig@lap200:~/C++/gcc3.4/tmp> cat test-BOOST_HAS_THREADS.cc #if defined(WITH_STRING_HEADER) # include <string> #endif #include <boost/config.hpp> #if defined(__MT__) # warning "__MT__ defined" #endif #if defined(_MT) # warning "_MT defined" #endif #if defined(_REENTRANT) # warning "_REENTRANT defined" #endif #if defined(_PTHREADS) # warning "_PTHREADS defined" #endif #if defined(BOOST_HAS_THREADS) # warning "BOOST_HAS_THREADS defined" #endif cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ test-BOOST_HAS_THREADS.cc cludwig@lap200:~/C++/gcc3.4/tmp> g++ -c -I ../boost_1_31_0/ -DWITH_STRING_HEADER test-BOOST_HAS_THREADS.cc test-BOOST_HAS_THREADS.cc:16:4: Warnung: #warning "_REENTRANT defined" test-BOOST_HAS_THREADS.cc:24:4: Warnung: #warning "BOOST_HAS_THREADS defined" I have no idea what the gcc developers recommend in order to detect multi-threading support or if this should be reported to the gcc developers as a bug. But it will certainly break many programs using Boost. A user can work around this problem by either including boost/config.hpp before any other headers (even Boost headers since boost/lexical_cast.hpp, for example, includes string before boost/config.hpp). Or the user builds everything with MT-support, even if the program itself is single threaded. Neither workaround is satisfying. Regards Christoph PS: FWIW, I could trace back the problem to a change in include/c++/i686-pc-linux-gnu/bits/gthr-default.h. This change was discussed in http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html. -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

4 21

Patch for linker problems wiith date_time
by Matthias Troyer 02 Jul '04

02 Jul '04

Dear Boosters, There are a few inline statements missing in the new version of the date_time library, causing multiple definitions and linkage problems. I have attached a diff. Matthias cvs diff -u boost/date_time/posix_time/date_duration_operators.hpp Index: boost/date_time/posix_time/date_duration_operators.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/date_time/posix_time/ date_duration_operators.hpp,v retrieving revision 1.1 diff -u -r1.1 date_duration_operators.hpp --- boost/date_time/posix_time/date_duration_operators.hpp 30 Jun 2004 00:11:11 -0000 1.1 +++ boost/date_time/posix_time/date_duration_operators.hpp 1 Jul 2004 14:31:57 -0000 @@ -17,39 +17,39 @@ /*** ptime operator functions ***/ // ptime & months - ptime operator+(const ptime& t, const boost::gregorian::months& m) + inline ptime operator+(const ptime& t, const boost::gregorian::months& m) { return t + m.get_offset(t.date()); } - ptime operator+=(ptime& t, const boost::gregorian::months& m) + inline ptime operator+=(ptime& t, const boost::gregorian::months& m) { // get_neg_offset returns a negative duration, so we add return t += m.get_offset(t.date()); } - ptime operator-(const ptime& t, const boost::gregorian::months& m) + inline ptime operator-(const ptime& t, const boost::gregorian::months& m) { // get_neg_offset returns a negative duration, so we add return t + m.get_neg_offset(t.date()); } - ptime operator-=(ptime& t, const boost::gregorian::months& m) + inline ptime operator-=(ptime& t, const boost::gregorian::months& m) { return t += m.get_neg_offset(t.date()); } // ptime & years - ptime operator+(const ptime& t, const boost::gregorian::years& y) + inline ptime operator+(const ptime& t, const boost::gregorian::years& y) { return t + y.get_offset(t.date()); } - ptime operator+=(ptime& t, const boost::gregorian::years& y) + inline ptime operator+=(ptime& t, const boost::gregorian::years& y) { return t += y.get_offset(t.date()); } - ptime operator-(const ptime& t, const boost::gregorian::years& y) + inline ptime operator-(const ptime& t, const boost::gregorian::years& y) { // get_neg_offset returns a negative duration, so we add return t + y.get_neg_offset(t.date()); } - ptime operator-=(ptime& t, const boost::gregorian::years& y) + inline ptime operator-=(ptime& t, const boost::gregorian::years& y) { // get_neg_offset returns a negative duration, so we add return t += y.get_neg_offset(t.date());

2 1

Re:[boost] Serialization of infinite double - from comp.lang.c++
by Robert Ramey 02 Jul '04

02 Jul '04

>> If you want to store a special 'token' to indicate 'infinity', you'll >> need to specifically parse for it. >Perhaps I could alter the behavior of the "ostream& operator<<(ostream&, >double)" (and istream)? >Any other idea for a solution would of course be just as welcome.... Problem - serialization of a float/double with an Infinite or Nan value Fails with a text archive. This is due to the fact that the this archive class depends upon implementation of stream I/o which apparently doesn't consider these values for floats. I would suggest making a small derivation from the standard text archive which overrides the existing implementation of the load(float &) and load(double &) with a slightly more elaborate one which can handle these values. There is an example in the manual on how to do this. I'm no sure whether or not this facility should be part of the standard text archive or not. Fast workaround - use the native binary archive which just saves/loads the raw bits without trying to interpret them. Robert Ramey

1 0

[Boost-bugs] [ boost-Bugs-984124 ] pool::purge_memory() does not reset next_size
by SourceForge.net 02 Jul '04

02 Jul '04

Bugs item #984124, was opened at 2004-07-02 08:06 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=984124&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pool::purge_memory() does not reset next_size Initial Comment: Calling purge_memory() does not reset next_size in the memory pool implementation. This means that repeatedly allocating then calling purge_memory() causes the pool to allocate a buffer of double the size each time, even though the number of objects remains small. Thanks, Edmund Kapusniak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=984124&group_i… ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

CVS Fingerprint problems
by Fernando Cacciola 02 Jul '04

02 Jul '04

Hi, I'm trying to commit something to CVS but I get a warning from TortoiseCVS saying that the server fingerprint has changed. This is wrong right? TIA Fernando Cacciola SciSoft

2 2

logging library
by John Torjo 02 Jul '04

02 Jul '04

Dear boosters, Finally, found some time to work on the logging library ;) (for those interested - find it at http://groups.yahoo.com/group/boost/files/logging.zip or http://www.torjo.com/code/logging.zip) note: this first draft works only for Win32 :( In short, it makes it very easy to log messages, while being efficient. And on top of that, it's thread-safe. Table of contents: ****** Declaring/defining logs ****** Log hierarchies ****** Modifier/ Log functions ****** Enabling/disabling of logs ****** Example ****** Declaring/defining logs Every log has: - a unique ID, by which you refer when you write to it - a name, by which you can modify its behavior (for example, enabling/disabling). The name is very useful so that you can manipulate multiple logs at once (for instance, disable multiple logs at once) and to be externally known - to easily manipulate logs at run-time. Also, this way is also easier to form hierarchies of logs (see below). Cutting to the chanse: // declare a log, in a header file BOOST_DECLARE_LOG(dbg) // define the log, in a source file BOOST_DEFINE_LOG(dbg, "app.dbg") // writing to the log BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; ****** Log hierarchies Logs can be hierarchical. In a hierarchy, a log inherits all anscestors' behaviors. Log A is said to be a descendant of Log B if when B's name starts with A's name (example: "app.charts.gui.dbg" is a descendant of "app.charts", but not a descendant of "app.err") When manipulating logs, you're always manipulating a hierarchy - the wildcard '*' stands for "anything" - see below. ****** Modifier/ Log functions When a message is written to a log, the following will happen: - first, check if the log is enabled. If so, continue. Otherwise, do nothing. - run all modifiers for this message - run all log functions for this message A modifier is a function that can modify the original message before it's printed to any destination. Examples can be: prefix the message with the current time, or prefix the message with the current thread ID. The log function is a function that will actually print this message to a destination. An example: void write_to_cout(const std::string &, const std::string &msg) { std::cout << msg; } When setting modifier/log functions, you're manipulating hierarchies of logs. Example: // add this modifier to all logs that start with "app" name add_modifier_func("app*", &write_prefix); // write all messages to cout add_log_func("*", write_to_cout); ****** Enabling/disabling of logs By default, all logs are enabled. You can specifically enable/disable some of them - wildcards work. Example: // disable all logs disable_logs("*"); // enable all dbg logs enable_logs("*dbg*"); Note that enabling/disabling is VERY EFFICIENT. In case a log is not enabled, the code after BOOST_LOG(...) is not executed AT ALL. Example: BOOST_LOG(app) << some_time_consuming_msg << std::endl; If 'app' is disabled, some_time_consuming_msg will not be executed. ****** Example // full sample found in logging.zip // Modifiers for all: // [type_of_message] original_message append_enter_if_needed add_modifier_func("*", &prefix_time, std::numeric_limits<int>::max() ); add_modifier_func("*", &append_enter); // Modifiers for app and its ascendants // <time> [type_of_message] original_message append_enter_if_needed add_modifier_func("app*", &write_prefix); // Modifiers for "app" only // <time> [Thread ID] [type_of_message] original_message append_enter_if_needed add_modifier_func("app", &prepend_thread_id, 0); // Log Functions // all messages are written to cout add_log_func("*", write_to_cout); // "app*" messages are written to file as well add_log_func("app*", write_to_file); // 'app' only and dbg messages are written to Output Debug Window as well add_log_func("app", write_to_dbg_wnd); add_log_func("*dbg*", write_to_dbg_wnd); int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing" << i << '-' << j << '-' << k; // written to both cout & the file & Output Debug Window BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; BOOST_LOG(warn) << "Logged-on Users approach max. limit"; BOOST_LOG(err) << "Too many users!"; BOOST_LOG(charts::gui) << "Creating main window" << std::endl; BOOST_LOG(charts::dbg) << "A debug msg coming from {charts} module" ; BOOST_LOG(charts::gui) << "Destroying main window" << std::endl; // disable all descendants of 'app' (not the 'app' itself) disable_logs("app.*"); BOOST_LOG(dbg) << "this won't be written" << std::endl; BOOST_LOG(app) << "However, this msg. will" << std::endl; enable_logs("app.dbg"); // specifically, only dbg log is enabled back now BOOST_LOG(dbg) << "this will be written - this log just got enabled" << std::endl; BOOST_LOG(err) << "this still won't be written" << std::endl; enable_logs("app.*"); disable_logs("app.dbg"); // now, all logs are back to the 'enabled' state BOOST_LOG(err) << "this will be written - all logs are enabled" << std::endl; // disable all logs disable_logs("*"); BOOST_LOG(err) << "this won't be written" << std::endl; BOOST_LOG(app) << "neither will this" << std::endl; BOOST_LOG(dbg) << "or this..." << std::endl; BOOST_LOG(warn) << "or this..." << std::endl; BOOST_LOG(info) << "or this..." << std::endl; // enable all dbg logs enable_logs("*dbg*"); BOOST_LOG(app) << "this won't be written" << std::endl; BOOST_LOG(dbg) << "this will be written" << std::endl; BOOST_LOG(info) << "this won't be written" << std::endl; // enable info log enable_logs("*info*"); BOOST_LOG(info) << "a simple info" << std::endl; /*** Console 18:59:44 [app] [Thread 1384] testing1-2-3 18:59:44 [app.dbg] this is a debug message, i=1 18:59:44 I just wanted to tell you something.... 18:59:44 [app.warn] Logged-on Users approach max. limit 18:59:44 [app.err] Too many users! 18:59:44 Creating main window 18:59:44 A debug msg coming from {charts} module 18:59:44 Destroying main window 18:59:44 [app] [Thread 1384] However, this msg. will 18:59:44 [app.dbg] this will be written - this log just got enabled 18:59:44 [app.err] this will be written - all logs are enabled 18:59:44 [app.dbg] this will be written 18:59:44 a simple info */ /*** Output Debug Window 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 A debug msg coming from {charts} module 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.dbg] this will be written */ /*** out.txt file 19:00:03 [app] [Thread 1384] testing1-2-3 19:00:03 [app.dbg] this is a debug message, i=1 19:00:03 [app.warn] Logged-on Users approach max. limit 19:00:03 [app.err] Too many users! 19:00:03 [app] [Thread 1384] However, this msg. will 19:00:03 [app.dbg] this will be written - this log just got enabled 19:00:03 [app.err] this will be written - all logs are enabled 19:00:03 [app.dbg] this will be written */ There's some more work - the docs also ;) , but I'm pretty happy with the first draft. What do you all think? Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

5 10

[program_options] Darwin/Unicode/DLL failure
by Vladimir Prus 02 Jul '04

02 Jul '04

Hello! As shown in http://tinyurl.com/2q5xe that program_options fails unicode_test_dll on darwin. It's the only failure there, does not happen with statically linked version, and happens at runtime. For some reason conversion from or to unicode fails. Since it's runtime failure, I have no idea what could be wrong, and why it only happens in DLL. I'd really appreciate if somebody has a clue. Even knowning what's being converted, and at which character the codecvt facet fails might help. Thanks in advance, Volodya

1 0

Re: Learning boost::MPL
by Dan 02 Jul '04

02 Jul '04

Thanks Maxim, I appreciate the help. I tried the code out, it works well, but I must confess that I don't understand how it works. It seems you start it at begin+1. I don't know why but it's probably related to the next question. What is happening on this line? mpl::plus<mpl::deref<mpl::_2>, mpl::_1> As near as I can tell you deref the iterator in <_2> and add that with _1. How does this _1 and _2 stuff work anyway? Thanks again! -Dan

3 2