March 2004 - Boost - lists.preview.boost.org

Re: [boost] Re: [config] Patch for Intel 8.0 + Dinkum lib
by Stefan Slapeta 23 Mar '04

23 Mar '04

Gennaro Prota <gennaro_prota(a)yahoo.com> wrote: // // FWIW, I always use at least the following in my .cfg file: // // /Qms0 // /Zc:wchar_t,forScope // -Qoption,c,--arg_dep_lookup // -Qoption,c,--alternative_tokens // // plus, when possible, /Za and -Qoption,c,--dep_name in the command // line. If you have other things that can be useful... Collecting the // switches that unleash the real beast living inside Intel C++ has // become sort of a hobby of mine :) // You can find all the front end switches at www.edg.com. -Qoption,c,--dep_name does not work for the VC 7.1 library (<locale> and others). But maybe this can be patched easily. Stefan *********************************** Stefan Slapeta Wien/Vienna, Austria http://www.slapeta.com

2 2

Design flaw in Date-Time Library?
by Wolf, Frank 23 Mar '04

23 Mar '04

Hi all, maybe this has already been discussed here!? I have a problem constructing an "time_period" object with a duration of zero which seems to be a special case not handled properly in my opinion. According the comments in one of the headers constructing a "time_period" with zero duration is not possible; i.e. the duration is at least 1. Whats the rationale to make construction of this special case possible then? (see code sample). That means what's the rationale not to handle the special case of a zero duration? Please see the following sample code: ------------------------------------------------------------------------ { // Contruct a time_period representing a whole day ptime pToday(date(2004, 2, 29) ); time_period wholeDay(pToday, time_duration(24, 0, 0) ); std::cout << to_simple_string(wholeDay) << std::endl; // Contruct a time_period representing just the next point of time ptime pTomorrow(date(2004, 3, 1) ); time_period wholeDay2(pTomorrow, time_duration(0, 0, 0) ); std::cout << to_simple_string(wholeDay2) << std::endl; // Our second period is not contained in the first one if (wholeDay.contains(wholeDay2) != false) std::cout << "Error" << std::endl; } ------------------------------------------------------------------------ gives: [2004-Feb-29 00:00:00/2004-Feb-29 23:59:59.999999] // Correct [2004-Mar-01 00:00:00/2004-Feb-29 23:59:59.999999] // Wrong? Error? // Wrong!!! >From my understanding the second time_period is not contained in the first one, but the design of the library gives such a result. Wouldn't it make sense to change the definition of the "time_period" class to handle the special case of a zero duration too? At least it should not be possible to construct a "time_period" with zero duration!? (But I would really favor a solution which regards a "ptime" equvalent to the special case of a "time_period" with zero duration). Regards, Frank ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. *******************************************

2 1

Compiler identification macros (please comment)
by Gennaro Prota 23 Mar '04

23 Mar '04

As recently come up (again) in the threads "Comment regarding __GNUC__ spoofing" "[config] Patch for Intel 8.0 + Dinkum lib" boost library developers have often a need to know the exact compiler in use, but they have no straightforward and easily maintainable way do that. The issue is that they can't just rely on compiler "identification" macros, as predefined by each compiler, because those are not *unique* to each compiler. Two typical cases are __GNUC__, which is defined both by g++ and Intel for Linux, and _MSC_VER which is defined by several compilers. A test for "real" g++, for instance, would look something like #if defined(__GNUC__) && !defined(__ICL) && !defined... which is unnecessarily tedious, error prone and hard to maintain. The problem would be solved if the config system exposed a macro for each compiler that it identifies. There seems to be agreement that this should be done, so please express your opinion about the names you prefer for the macros, or tell why you don't want them. I heartedly ask for *short* names, because preprocessing lines become easily enourmous otherwise (the typical test has the form: #if defined(MACRO_NAME) && (MACRO_NAME <= xx)). Currently, there are 16 config files in boost/config/compiler/ but we don't need so much macros immediately. So I just propose the following (other ones can be added on an "as needed" basis): BOOST_BORLAND BOOST_COMEAU BOOST_GNU (1) BOOST_INTEL BOOST_MSVC (2) ---- Notes: (1) since the other macros employ the name of the producing company, rather than the name of the compiler, BOOST_GNU seems more consistent than BOOST_GCC (though, of course, GNU is not a "company") (2) this is inconsistent, but it already exists. Maybe BOOST_MICROSOFT, or BOOST_MS, could be provided as a synonym. Genny.

9 10

RE: [boost] Re: boost FSM and another idea
by Hanson, Iain 23 Mar '04

23 Mar '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: 23 March 2004 03:11 > > Not meant to compete with Andreas' submission, but I've enclosed the > latest FSM examples from the upcoming MPL book. ^^^^^^^^^^^^^ These didn't show up on the list and they didn't show up on the list archive either. /ikh ------------------------ #include <std_disclaimer> ------------------------ Everything following this line has been provided courtsey of my ISP and I have no control over it. ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================

1 0

Dispatch question
by Angus Leeming 23 Mar '04

23 Mar '04

This from BufferView::Pimpl::workAreaDispatch: // Try to dispatch to an non-editable inset near this position DispatchResult res; if (inset) inset->dispatch(cur, cmd); // Dispatch to the temp cursor. // An inset (or LyXText) can assign this to bv->cursor() // if it wishes to do so. if (!res.dispatched()) res = cur.dispatch(cmd); I think that the code is a relic of the (not so distant) days when Inset::dispatch returned a DispatchResult rather than void. Should it not be rewritten as: if (inset) inset->dispatch(cur, cmd); DispatchResult const res = cur.dispatch(cmd); Or even as: DispatchResult const res = cur.dispatch(cmd); ? It seems to me that the cursor is now responsible for initiating the dispatch to the correct inset. Help! ;-) Angus

2 2

physical_quantities v1-00-03
by Andy Little 23 Mar '04

23 Mar '04

Hi again, pqs-1-00-03-boosted is available on the files section: http://groups.yahoo.com/group/boost/files/pqs/pqs-1-00-03-boost.ZIP This version is designed for inclusion in the boost library tree. and uses the namespace boost::pqs, where previous versions used physical-quantities. Tested on VC7.1 and gcc3.2. Currently I am working on complex physical-quantities which require a large number of operator overloads, and cant be achieved without violating the standard. 26.2.6.(See the q_complex.cpp and complex_example.cpp in examples for details of whats done so far in complex area.) Does pqs use mpl? Some but not much. I have had difficulties using mpl in this context. Which is basically to construct the return types of operators. I have found that this type of thing does the job in a scaleable manner: binary_operation<A,Op,B>. This computes a type and has a solitary result_type member which can be used with result_of. It also scales rather well and has come in very useful for complex physical-quanity definitions as well as my abstract_pq type. (see boost/pqs/class_template/abstract_identity/abstract_pq/abstract_pq.hpp in the distro for example of economies gained by this approach). Defining binary_operation<A,Op,B> for two types also automatically enables use of the binary_operator functors.(See boost/pqs/operators/binary_operators.hpp in the distro for details on this.) Major changes based on boost feedback 1) The namespace in this version has changed from physical_quantities to boost::pqs. 2) A tag mechanism has been added to distinguish (say) torque from energy. This works simply at the output level. See examples/torque_from_energy.cpp for more details. I still do not consider the library to be stable yet.(There may be a need for yet another tag in the units) I dont have any tests included, and the docs need a lot of work. At the moment it is still just for fun. regards Andy little

4 8

[signals] simplest usage not working
by Vladimir Prus 23 Mar '04

23 Mar '04

Hello, trying to compile the following program gives me compile errors: #include <boost/signals.hpp> void print_sum(float x, float y) { } int main() { boost::signal<void (float, float)> sig; sig.connect(&print_sum); return 0; } The compiler output is in the attachment and I've tried with two gcc versions: gcc version 3.3.3 20040125 (prerelease) (Debian) gcc version 3.4.0 20040222 (prerelease) (Debian) The program fails to compile even when I remove the "connect" call. I'm using the up-to-date CVS tree. The examples also fail to compile. I don't know what to think, especially given that regression tests look ok. The preprocessed source, if that's of any help, is at http://zigzag.cs.msu.su:7813/st2.ii.bz2 Thanks in advance, Volodya

2 1

RE: [boost] boost::lambda::operator* and smart pointers
by Eyal Farago 23 Mar '04

23 Mar '04

I think this level of indirection is already encapsulated in boost::pointee. eyal. -----Original Message----- From: Maxim Yegorushkin [mailto:e-maxim@yandex.ru] Sent: Saturday, March 20, 2004 4:50 AM To: boost(a)lists.boost.org Subject: [boost] boost::lambda::operator* and smart pointers Hi guys. I encountered a pitfall when trying to use boost::lambda for dereferencing a smart pointer. Current lambda implementation assumes that operator*() can be applied to either a plain pointer or an iterator. That leads to an error message when applying the operator to a smart pointer complaining about std::iterator_traits<> not being specialized for the smart pointer. Consider the code: struct some { void foo(int); }; boost::shared_ptr<some> ptr(new some); ( lm::bind( &some::foo , *lm::_1 , 0 ) ) (ptr); the bind expression won’t compile until we hack std::iterator_traits<boost::shared_ptr<> >: template<class T> struct std::iterator_traits<boost::shared_ptr<T> > : std::iterator<void, T> { }; My point is: why don’t add an additional level of indirection for boost::lambda::detail::contentsof_type<> so that the indirection will allow the user to specialize it for smart pointers? -- Maxim Yegorushkin MetaCommunications Engineering http://www.meta-comm.com/engineering/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

boost::lambda::operator* and smart pointers
by Maxim Yegorushkin 23 Mar '04

23 Mar '04

Hi guys. I encountered a pitfall when trying to use boost::lambda for dereferencing a smart pointer. Current lambda implementation assumes that operator*() can be applied to either a plain pointer or an iterator. That leads to an error message when applying the operator to a smart pointer complaining about std::iterator_traits<> not being specialized for the smart pointer. Consider the code: struct some { void foo(int); }; boost::shared_ptr<some> ptr(new some); ( lm::bind( &some::foo , *lm::_1 , 0 ) ) (ptr); the bind expression won’t compile until we hack std::iterator_traits<boost::shared_ptr<> >: template<class T> struct std::iterator_traits<boost::shared_ptr<T> > : std::iterator<void, T> { }; My point is: why don’t add an additional level of indirection for boost::lambda::detail::contentsof_type<> so that the indirection will allow the user to specialize it for smart pointers? -- Maxim Yegorushkin MetaCommunications Engineering http://www.meta-comm.com/engineering/

2 2

mpl::vector<void> compiler bugs?
by Larry Evans 23 Mar '04

23 Mar '04

The attached file gets following output: <-------------- cut here --------------- como -c --timing --long_long --display_error_number --diag_suppress 76 -I/home/evansl/prog_dev/boost-root.ln/boost_dev -I/home/evansl/prog_dev/boost-root.ln -o vec_void_const_bug.o vec_void_const_bug.cpp Comeau C/C++ 4.3.3 (Jan 30 2004 15:40:54) for LINUX_INTEL_ELF Copyright 1988-2004 Comeau Computing. All rights reserved. MODE:non-strict warnings C++ Front end time 0.76 (CPU) 1.00 (elapsed) Back end time 0.02 (CPU) 0.00 (elapsed) Total compilation time 0.78 (CPU) 1.00 (elapsed) como -o vec_void_const_bug.exe vec_void_const_bug.o running vec_void_const_bug ./vec_void_const_bug.exe mt_var: member_target(vector<void> const&) mt_con: mt_cast: member_target(vector<void> const&) end: >------------- cut here --------------------- When it should get the same output after mt_con: as it does for mt_var: and mt_cast:. I get similar problems with g++3.4 and intel 8.0. Are all these compilers wrong or am I missing something? TIA.

1 2