- Boost - lists.boost.org

Interfaces Library (structural subtyping)
by christopher diggins 28 Jan '05

28 Jan '05

Several people have told me the technique which I referred to as "retroactive polymorphism" is more correctly labelled "structual subtyping". Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

boost/bind.hpp patch (was Re: Compiling boost on tru64 (Richard Hadsell))
by Kevin Wheatley 28 Jan '05

28 Jan '05

Peter Dimov wrote: > Mark Helzer wrote: > > Kewl, that works, I got a little further down the path. Next problem: > > > > cxx: Error: /adp/local/src/boost_1_32_0/boost/bind.hpp, line 206: #266 > > "value" is ambiguous > > Can you please try adding _bi:: in front of value and see if this fixes the > problem? The following patch (against 1.32) certainly allows the MIPS Pro compiler to compile that file without the two ambiguity errors. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself | --- /tmp/bind.hpp.orig Fri Jan 28 10:56:34 2005 +++ /data/RnD/3rdPartyLibraries/www.boost.org/boost_1_32_0/boost/bind.hpp Fri Jan 28 10:55:52 2005 @@ -203,9 +203,9 @@ A1 operator[] (boost::arg<1> (*) ()) const { return a1_; } - template<class T> T & operator[] (value<T> & v) const { return v.get(); } + template<class T> T & operator[] (_bi::value<T> & v) const { return v.get(); } - template<class T> T const & operator[] (value<T> const & v) const { return v.get(); } + template<class T> T const & operator[] (_bi::value<T> const & v) const { return v.get(); } template<class T> T & operator[] (reference_wrapper<T> const & v) const { return v.get(); }

1 0

[any] ostream inserter
by Sérgio Pace 28 Jan '05

28 Jan '05

Hi, I was playing with the any.hpp library trying to add a generic inserter to an ostrem. To acomplish that I created a pure virtual method print in the placeholder: class placeholder { ... virtual void print(std::ostream& out) const = 0; ... } implemented it in the template holder template<typename ValueType> class holder : public placeholder { ... virtual void print(std::ostream& out) const { out<<held; } ... }; and last but not least I implemented the inserter i the any class: class any { ... friend std::ostream& operator<<(std::ostream& out, const any& data) { data.content->print(out); return(out); }; ... }; this was my first attempt and I expected it to work fine, but to limit the use of any to classes that implement inserters, but I had a nice surprise to find out that as long I don´t actually invoke the inserter on non inserter implementing contained objects everything work fine, at least in bcc 5.5 and gcc(mingw) 3.4.2. when I do use the inserert operator for a nom implementing contained object I get a stack overflow exception, it seens like the inserter operator call the print method and print invoke the any inserter instead of the contained object inserter. Beeing able to strem out a unknow object is a huge plus in my current project and I thing it will be a great addition to the library, but I´m wondering how portable (standard compliant?) is my solution and why this recursive call happens with non inserter objects. Sorry if my explanation was not very clear or bad english, this is my first post in this mailing list and english is not my native language. just mail any need for clarifications. Sérgio

5 8

Is this a legal approach to template definition separation
by JOAQUIN LOPEZ MU?Z 28 Jan '05

28 Jan '05

This is not strictly related to Boost, but its motivation comes from an effort to reduce compilation times for a Boost library, so I'll risk posting the question. Consider the following: // *************** some_class_template.hpp *************** #ifdef INCLUDE_DEFINITION # define BODY_INCLUDED 1 #else # define BODY_INCLUDED 0 #endif #define BODY_DEFINITION(body) BOOST_PP_IF(BODY_INCLUDED,body,;) template<typename ...> class some_template_class { ... void f(...) BODY_DEFINITION(( { // implementation of f goes here } )) ... }; // *************** foo.hpp *************** #include "some_class_template.hpp" class foo { void bar(); private: some_class_template<...> m; }; // *************** foo.cpp *************** #define INCLUDE_DEFINITION #include "user.hpp" void foo::bar() { m.f(); // f is defined, OK to use it. } Well, the idea is to generate in a simple way a declaration only header of a template class from the full definition, for those situations when the definitions are not needed. The purpose is to reduce compilation times in those translations units including foo.hpp, as they won't be using the class template directly. Other, more conventional approaches, like having the definitions of the class template out of line in a separate file, are harder to maintain and proved to be problematic with buggy compilers (MSVC++ 6.5.) Yet another alternative is to use the pimpl idiom, but this has a runtime penalty. My question is: is this ODR compliant? Anyone sees a problem with this approach? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[function] virtual function bloat
by Jonathan Turkanis 28 Jan '05

28 Jan '05

Hi, I'm writing documentation for my interface library comparing the performance of interfaces vs. base classes with virtual functions. I was going cite a reduction in code bloat caused by virtual functions, with a link to the Boost.Function docs. But when I read the function docs again I was surprised: I had thought the bloat was caused by duplicate vtables being placed in different translation units; I see instead that the bloat cited is attributes to auxiliary type-classification functions. In the interface library I construct artificial vtables containing pointers to free functions, but each table has a slot reserved for a function which allows the type of the bound object to be partially recovered. Could this extra function mean that any improvement in code size achieved by eliminating virtual functions has been canceled out? I realize I haven't given much info about my library; I can supply more if necessary. Any insight would be greatly appreciated. Jonathan

2 2

[function] function_base.hpp comile error with bcc32-5.6.5
by Roman Morokutti 28 Jan '05

28 Jan '05

I am trying to compile the boost libraries. I encountered a compile error with bcc32: Error E2437 D:\boost\boost_1_32_0\boost/function/function_base.hpp 598(55): 'typename' should be followed by a qualified, dependent type name Can someone help? Greetings Roman

3 3

[mpl] Possible documentation bug
by Brad Austin 28 Jan '05

28 Jan '05

The MPL Reference Manual page for at_c: http://www.boost.org/libs/mpl/doc/refmanual/at-c.html Contains the following sample code: typedef range_c<long,10,50> range; BOOST_MPL_ASSERT_RELATION( (at_c< range,0 >::value), ==, 10 ); BOOST_MPL_ASSERT_RELATION( (at_c< range,10 >::value), ==, 20 ); BOOST_MPL_ASSERT_RELATION( (at_c< range,40 >::value), ==, 50 ); Does at_c<unspecified>::value exist? I get a compilation error: error: `value' is not a member of type `boost::mpl::at_c<range, 0> '

2 1

[graph] Any plans to finish implementing subgraph?
by David M. Jones 28 Jan '05

28 Jan '05

Hi, I am using the subgraph class template in my work and I have noticed a number of issues. (1) I am unable to use boost::listS as the storage type for vertices or edges. I see that this is because the association between the local and global vertices is stored (in part) in a std::vector. Is there a plan to support subgraphs of non-array-indexed graphs? (2) The remove_edge_if() and clear_vertex() functions have comments stating that they are wrong. Are the functions wrong or are the comments wrong? If the functions are wrong, is there a plan to fix them? (3) The remove_vertex() function states that it is "under construction". Who is doing the construction? Is there a time-frame for this? I am asking these questions because I don't want to work on my own fixes/implementations of these issues if someone else is already putting forth the effort. Thanks, David

2 2

Re: [boost] boost.filesystem - rationale for copy_file
by Victor A. Wagner Jr. 28 Jan '05

28 Jan '05

At Thursday 2005-01-27 14:32, you wrote: >From: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > > At Tuesday 2005-01-25 14:28, you wrote: > > > > >What is the rationale for having copy_file fail if the target file > > >exists? > > > > > >This is not how any cp/copy in any shell I know of works, actually > > >quite surprising. > > > > in windows (and every OS I've been on the writing team) the shell will at > > least _ask_ for permission to overwrite. > >*nix cp has a -i option to query you, but the default behavior is >to overwrite quietly. The shells do nothing to change that. I wasn't on the team that wrote any flavor of *nix >-- >Rob Stewart stewart(a)sig.com >Software Engineer http://www.sig.com >Susquehanna International Group, LLP using std::disclaimer; >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

RE: cant i use mpl::contains to find members of list_c ??
by Jaap Suter 28 Jan '05

28 Jan '05

> I was trying to use mpl::contains with list_c and it always seems to > return mpl::false_. > For example > typedef mpl::list_c< int ,16,8 > mylist; > typedef mpl::contains<mylist, mpl::int_<16> >::type tt; I've run into this issue in the past as well, and I vaguely rememember seeing mpl::integral_c<long>'s being used somewhere along the way, instead of mpl::integral_c<int>'s as one would expect. I'm not sure if that is still the case, or whether I was decaffeinated, but I ended up fixing it by using the following work-around (pseudo-code): template<class Sequence, class Elem> struct contains : mpl::contains < Sequence, mpl::integral_c < mpl::front<Sequence>::value_type, Elem::value> > >{}; Which isn't pretty, but it got the job done. You basically get the value_type of the first element in the sequence, to make sure the base type of the integral_c you're looking for matches with the sequence. I'm hoping Alexsey or Dave will step in here and clarify this, as it has been a source of confusion for me as well. Regards, Jaap Suter

2 1