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

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

[ANN] Interfaces Library
by Jonathan Turkanis 27 Jan '05

27 Jan '05

I am pleased to announce the much anticipated (by me) release of a preliminary version of my interfaces library. The download page and online docs are here: http://www.kangaroologic.com/interfaces/ (For fun, click on "Online Documentation" and then on the Boost logo.) The library is an implementation of Christopher Diggins's proposal to add interfaces to C++, which was posted on comp.std.c++ early last year and later was described in the C/C++ User Journal. It provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the "dot" operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particular base class. Current applications include: * Non-intrusive dynamic polymorphism - interfaces can often be used in place of abstract base classes, and are sometimes much faster. * Dynamic inheritance - allows function calls to be forwarded automatically to an object specified at runtime. * Smart Interface Pointers - smart pointers which can manage the lifetime of any object whose type implements a given interface. * Smart References - like smart interface pointers, but the managed object is accessed using the dot operator. * The Object Oriented Template Library, a project in the initial stages of development, by Christopher Diggins. Planned future applications include: * Runtime reflection - will allow an interface's functions to be enumerated and looked up by name at runtime * Aspect Oriented Programming as described in a August 2004 Dr. Dobb's Journal article by Christopher Diggins. Possible future applications include: * Integration with component architectures such as COM and CORBA. * Boost.Names - by abstracting the various uses of identifiers in C++ into preprocessor generated types called names, C++ classes and functions can be constructed in a straightforward manner using template metaprogramming. Best Regards, Jonathan

6 12

[ANN] range algorithms and adaptors
by Eric Niebler 27 Jan '05

27 Jan '05

I just uploaded to the boost-sandbox a set of range-based algorithms and adaptors. The algorithms are based on container_algo.hpp from the sequence_algo library (Thorsten Ottosen, Jeremy Siek, Vladimir Prus). I have reimplemented them on top of Boost.Range, and changed the modifying algorithms to work with ranges that are physically const but logically non-const (such as std::pair<char*,char*> const). I have also implemented range adaptors, which are built on top of Boost.Range and the iterator adaptors in Boost.Iterator. There are transform, filter, reverse and indirect range adaptors. They combine with the range algorithms and with BOOST_FOREACH. Consider the following which takes a list of Widget pointers and finds a Widget which is visible and that is named "This Widget": list<Widget*> widgets = ...; list<Widget*>::iterator = find( widgets | indirect | filter(bind(&Widget::Visible,_1)) | transform(bind(&Widget::Name,_1)) , "This widget" ).base().base().base(); And consider the following, which loops over a vector in reverse order: vector<string> strings = ...; BOOST_FOREACH( string & str, strings | reverse ) { cout << str << '\n'; } The code is in boost-sandbox at boost-sandbox/boost/range_ex. I have also put a range_ex.zip in the file vault at: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler No docs or tests yet. This is a work in progress. Feedback welcome. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

What is the status of associative vector framework?
by ION_G_M 27 Jan '05

27 Jan '05

Hello to all, While developing Boost Shmem, I needed an associative container to store data in shared memory, and the easiest one to develop was an ordered vector. For this, I'm using a slightly modified version of Loki's AssocVector (just added reserve() and capacity() members to adjust memory and boost performance in some cases). Reading Boost Files section, I've seen an associative_vector directory containing a preliminary version of this class and related mails, but I don't see any more references to this class since 2002. In the Formal Review Schedule page it is not listed but I can see some review mails googling around so I was asking if this library was abandoned for any reason. I think that this king of "flat" associative containers are very useful, since they are normally faster than std::set/map in lookups and more memory friendly, specially for small types, since normally a tree like structure imposes an overhead of 3 pointers and an integer per node. That without counting that memory allocation for a vector has far less fragmentation when using std::allocator. Is the library still alive? Is anyone insterested in these classes? What I propose is a std::set/map/multiset/multimap like interface on an ordered vector, without more advanced functions, perhaps with added reserve/capacity interface to optimize memory allocation when the number of elements is known beforehand. Best regards, /Ion ---EOF---

1 0