- Boost - lists.boost.org

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

patch for STLport debug libs without stldebug-mode
by Ulrich Eckhardt 22 Mar '04

22 Mar '04

Hi! I discovered to my dismay that the boost_thread lib that uses STLport uses STLport's special debug mode. I therefore prepared a patch (against 1.31.0) that renames the current 'debug' target to 'stldebug' and adds a new 'debug' target that only uses the normal debug version of STLport. There are a few issues to discuss though: - I'm no expert of the build-system, not even an adept. I just tried to understand what's going on and tried until it seemed to work. It is a little tested on MSVC6. - I have no idea why the special debug-mode was introduced as default in the first place, I haven't found anything that tells why. - I found a note in one of the bbuild v2 files (which I did neither use nor patch) saying that 'normal debug' is not supported. Again, why and why isn't that stated in the notes for the *-stlport toolsets? - regex(IIRC) uses a 'd' in the resulting lib to mark debug libs and 'dd' to mark libs with special debug modes like STLport's. I adapted this naming convention when making the patch. In case anyone wonders, I work in an environment where I just don't have the extra time for STLport's debug mode. any comments welcome Ulrich Eckhardt

2 2

Re: [boost] Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 22 Mar '04

22 Mar '04

Hello Brian, thank you for reviewing indexed_set! ----- Mensaje original ----- De: Brian McNamara <lorgon(a)cc.gatech.edu> Fecha: Domingo, Marzo 21, 2004 1:00 am Asunto: Re: [boost] Formal Review: Indexed Set > > I read the "tutorial" and only glanced at the other sections. The > documentation is quite good. A few quick comments: > > Some of the code examples in the tutorial have lines longer than 80 > chars and they don't render well in my browser. Breaking the long > lines into multiple lines will easily fix this. > > At one point in the tutorial it says "nth_indexed_type" instead of > "nth_index_type". The same (extra "ed") bug is repeated again > shortly after the first one. Thank you, I'll fix these. > > I had to manually > #include "boost/indexed_set/sequenced_index.hpp" > in addition to > #include "boost/indexed_set.hpp" > in order to get "sequenced" to work. Not sure if this is a bug in > the docs or a bug in the library itself; either it should be included > automatically, or else the docs should mention including it manually. Well, this is not actually a bug, buy an issue I would like people to give their opinion about, along with other naming and organizatinal issues. If you feel in the mood, please take a look at the review notes at http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html Pavel has started an independent thread to treat these points. > > The docs mention > #define BOOST_INDEXED_SET_ENABLE_INVARIANT_CHECKING > for both "safe mode" and "invariant checking mode". I did not look > into this enough to decide if there is (or is supposed to be) a > different separate flag to set for "safe mode". > It's a bug in the docs. There exists a separate BOOST_INDEXED_SET_ENABLE_SAFE_MODE macro. Thank you for spotting this out. [...] > At one point, when using tags, I did something like > > struct by_seq {}; > ... sequenced<by_seq> ... // oops, should be > sequenced<tag<by_seq> > > > and got a compiler error. (BTW, the docs are not totally clear here; > they should say that you need tag<...>.) [...] Well, the requirement is stated at the referece, though it won't hurt to say it more explicitly in the tutorial. I'll try to improve this. > I noted with some dismay that duplicate tags are not detected. That > is, you are allowed to say > > struct by_id {}; > struct by_name {}; > struct by_foo {}; > typedef indexed_set< > employee, > index_list< > unique<tag<by_id,by_foo>,identity<employee> >, > > non_unique<tag<by_name,by_foo>, > member<employee,std::string,&employee::name> > > > > > employee_set; > > where I have named both indices "by_foo". I would prefer it if the > library detected this as a BOOST_STATIC_ASSERT-able error. > Currently, the approach is that the first index with a given tag is picked (the reference states this explicitly). I'm not convinced the approach you suggest is more convenient: maybe eliminating such duplicate tags in a metaprogramming environmnt (imagine the indexed_set is instantiated by an automatic framework) is not that simple. A static *warning* would be ideal here :) > > > Do you think the library should be accepted as a Boost library? > Be > sure to say this explicitly so that your other comments don't > obscure your overall opinion. > > Yes. great ;) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2