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

Virtual member functions cause exception in get_derived_class_object
by David Rostowsky 02 Apr '04

02 Apr '04

I have a couple of really simple classes: class MyBase { public: int x; virtual int foo(int new_x) { }; // our derived classes may or may not override this function. Coders choice. }; class MyDerived: public MyBase { public: int y; MyDerived() { y = 0; }; int Get(void) { return y; }; void Set(int val) { y = val; }; }; My main goal in life is to create an instance of MyDerived class in C++: MyDerived my_derived = new MyDerived(); and then pass the pointer to a Python script where the Python script can call any of the public member functions. Yes, I am careful to keep the pointer around in the C++ code while the Python script uses it. So I expose the class (this may or may not be the source of my problems, need help): BOOST_PYTHON_MODULE(test) { using namespace boost::python; class_<MyDerived>("MyDerived") .def("Get", &MyDerived::Get) .def("Set", &MyDerived::Set) ; } /* test*/ My impasse is that the virtual function seems to really give Boost hell when Im trying to pass the pointer to the class over to the python script. Heres the code snippet for that. Its the conversion thats just KILLING me. If I comment out the virtual function, everything works perfectly! I can pass the pointer over to my script, it calls the public member functions, and Im happy. HOWEVER, if I put the virtual function back in, the following line of code just EXPLODES! // It crashes and burns in make_ptr_instance.cpp, function get_derived_class_object() boost::python::object my_arg(boost::ref(my_derived)); // pass the pointer over to the script now. int rval = callPython("myTestFunc", "Test String argument from c++", my_arg); Im completely frustrated by this. I need some psychological help! Thanks in advance! Dave

4 9

BCP error for 1.31 on Windows
by Edward Diener 02 Apr '04

02 Apr '04

I built bjam for 1.31 and then I built bcp for 1.31 using MingW/GCC 3.3.1 using bjam version 1. I then opened a command prompt, went to the root directory of my Boost 1.31 distribution and tried: bcp --list shared_ptr I received this error message: **** exception(205): std::runtime_error: Error opening for output. ******** errors detected; see standard output for details ******** I then went to the boost subdirectory of my Boost 1.31 distribution and typed the same command as above and received: no errors detected but no other output was printed on standard out. I am just trying to get a list of any dependencies which shared_ptr has using bcp. What am I missing in this entire procedure ? It does not appear that bcp is working correctly but maybe I am missing something in how it should be working.

2 3

[boost-users] Re: [boost] [BGL] forced client complexity
by Cromwell Enage 02 Apr '04

02 Apr '04

prs, On reflection, I've decided to cross-list my reply. > If one accepts the axiom that "a picture is worth a > thousand words," then it naturally follows that > discussion of graphs is always overly prolix. I recently had a chat with a fellow programmer and attempted to summarize, in semi-layman terms, how the core algorithms of my multi-state-mazes library work. They're pretty simple, but I couldn't do it without paper and pencil. > Sadly, the same reasoning is also applicable to > the code of graph libraries. If a "code-visualizing compiler IDE" existed that would give us "code pictures" (plus conform to the new C++ standard, not ICE, and so on), I'm pretty sure more of us would be using it for all programming projects, not just graph applications. :) But seriously, with graph theory containing several different problem domains (search, network, AI, etc.), a graph library attempting to be generic enough for use in all of them is necessarily complex. > Boost.Graph seems to expose and require an > unnecessarily large amount of complexity, > though. If by "exposure" you mean lots of source code, I'll take that complexity any day of the week and twice on Sundays. :) The library does have a rather steep learning curve, especially if you're somewhat unfamiliar with graph theory and/or template programming. > Whereas libraries like Spirit go to great lengths > to make hard things easy, BGL seems to try only to > make hard things possible. I haven't looked at the Spirit library yet, so I can't tell you how easy it may be to use it. Perhaps getting your hands on a copy of the Boost Graph Library book will help (I don't have one, so I'm not certain). > The amount of scaffolding required > to use BGL for even the simplest of projects > often dwarfs the code size of a naive, > yet functional, special-purpose implementation. Special-purpose implementation of a graph library? Or the project? BGL aims to be as generic as the STL, but whereas each STL container deals with essentially one type of element, a graph needs to contain two types: a vertex type and an edge type. Furthermore, while most STL algorithms confine themselves to handling just those STL container elements, most graph algorithms also need the properties of vertices and/or edges as input. BGL delegates some of the responsibility of property storage to the Boost Property Map Library. I'm just glad the developers kept the complexity down to its current level. > While I understand that the BGL is deeply entrenched > in boost culture, certain academic circles, and even > publications, I nonetheless suggest that BGL lacks > the ease of use necessary for widespread adoption. Having dwelt in the academic circle known as the University of Central Florida, and thus familiar with the theoretical uses of a graph library (plus I've studied some game development apps on the side), I'd like to learn more about how the Real World would want to use BGL. > Even knowing that ease-of-use is not a criterion > for acceptance into boost, looking at what is > required of the client to use the BGL always leaves > me feeling perplexed. Is there any particular reason > that a simplified interface is not made available? Again, I don't know a simple graph problem that requires a simplified graph interface. > Perhaps a container adapter could be packaged with > the library allowing a compromise of functionality > and flexibility for simplicity? I thought the boost::vector_as_graph class template served that purpose. Wrap it around a std::vector<EdgeList>, with EdgeList = std::list<unsigned int> (or an edge list container of your choice, so long as the value type is usable as an index in the vector), and you should be good to go. > If a graphing problem is trivial, shouldn't BGL > provide a trivial solution? Why are the simplest > useful examples several hundred lines of code? The examples don't seem that big and hard to understand. Of course, quite a few of them have #ifdefs that I could do without since I don't use the compilers in question, but I can live with them. > I apologize for all of my vague criticisms - my > intention is not to flame but rather to test the > waters. Your criticisms seem healthy, and I hope my responses are helpful. > It is difficult for me to assess whether the > simplicity I yearn for isn't present for stylistic > reasons or whether it would rather necessitate a > sacrifice of flexibility, functionality or > implementation clarity. Nor is it clear to me to > what extent these criteria can be compromised to > promote clarity of client code. For what it is > worth, the kind of ease-of-use I'm imagining might > look like: #include <less_than_10_graph_headers> ... digraph<some_node_type,some_edge_context_type> g; g << "vertex" << make_pair("vertex", "implicit_vertex"); g.add_edge("brother", "sister", "sibling"); if(g.find(make_pair("brother", "sister"))) related = true; > Could someone please elucidate on why it is > impossible/impractical/unnecessary/whatever for a > graph library to have such an interface? I believe the potential for ambiguity would hinder this syntax the most. In this case, you'd have to overload operator<< to input both edges and vertices, and what if some_node_type turned out to be std::pair? You couldn't pass in make_pair(vertex,vertex) as an edge then. The same goes for g.find(); is it supposed to find a vertex, an edge, or both? Also, it seems you want to be able to use non-built-in or custom types as vertex IDs. You'll have to build your own custom-type-to-vertex map and bind it to the graph; BGL won't do it for you, to retain its genericity. Incidentally, BGL favors free functions over member functions. The rationale for that can be found in the FAQ <http://www.boost.org/libs/graph/doc/faq.html>. > Should I accept that the BGL is not the magic bullet > graph library and move on, or can this kind of > simplicity be somehow found within? Yeah, no magic bullets here. It depends on the problem you are trying to solve. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

2 1

IndexedSet Review: unified proposal for naming
by Joaquín Mª López Muñoz 01 Apr '04

01 Apr '04

I don't think any more people will join the review, so I've collected all the contributions regarding naming issues and tried to come up with a "unified" naming scheme. As it was expected, suggestions vary wildly, and the choicespan is growing as the review advances, so maybe this is a good time to try to reach a compromise. Please note everybody will have a favorite alternative, but the idea is that this proposal at least satisfies everybody and is abhorred by nobody. I'd appreciate if you take a look at the proposal and either accept it or provide strong argument against it (or against parts of it). It would help if further discussions conform more or less to the structure of this proposal, so as to ease gathering results later. Also, I'm not the review manager and it is not for me to make the final decision on this and other issues, but I think some preprocessing work could be beneficial. So: NAMESPACE * Proposal: boost::container::multi_index * Rationale: The name suggests what the library is about and does not clash with the name of the container. Preferred to multiindex as English seems to like the former better. In favor of multi_index: Rob, Pavel (underscore-less variant), Arkadiy (for the container instead), Jeff, Thorsten, Paul, Matthew (only if pushed into boost::container). Alternatives: non-descriptive name (Tom), multi_indexed_containers. * Why inside boost::container? Seems like there's a general move to 2nd level namespaces, and this in particular saves us from repeating "container" in the library namespace itself. If anything, being the only library inside boost::container does not hurt. I've scanned the posts and these are the reviewers' opinions about this subject matter: In favor of pushing into boost::container: Matthew, Joerg Against: Dave Not sure: Jeff Don't care: Gary, Darren CONTAINER NAME Proposal: composite_container. Rationale: It more or less suggests what it is. "index" does not appear in the name, but to compensate it'll show anywhere else (the namespace and the parameters like index_list) so the index concept is ubiquitous. It does not use "set" as composite_container in general is not a set. It matches the concept it'll model in the future (when this section is written.) Alternatives proposed by reviewers: indexed_set, multicontainer, indexed_table, table, indexed, composite_set, set (distinguised from std::set by the namespace). LIFTING TO NAMESPACE BOOST * Proposal: container lifted only one level: boost::container::composite_container * Rationale: Lifting to boost seems too long a jump, and lifting to both places is overkill. LIBRARY NAME * Proposal: Boost Multi-index Container Library * Proposal for short form: BMCL * Rationale: The name is descriptive enough, and gives room for future containers to be added here (indexed maps, the infamous bimap, etc.) REGULAR INDICES * Proposal: Name changed to "ordered indices". * Rationale: The name is far more descriptive. When first met, "regular" means nothing. Allows for a nice solution to the clash with std::unique (see below). INDEX NAMES * Proposal: "unique" and "non_unique" changed to "ordered_unique" and "ordered_non_unique". * Rationale: No one opposed and some liked it. Solves the clashing with std::unique. Extends nicely to hashed indices (unordered_unique etc.) It is more descriptive. In favor: Gary, Dave. Rob dislikes the unique/non_unique suffix, but alternatives do not look better IMHO. NTH_INDEX_TYPE AND FAMILIY * Proposal: nth_index<N>::type index<Tag>::type nth_index_iterator<N>::type nth_index_const_iterator<N>::type index_iterator<Tag>::type index_const_iterator<Tag>::type * Rationale: It eliminates the dreaded "_type" suffix. It does not clash with inherited "iterator" and "const_iterator" types. Two reviewers loved it (Darren, Dave), the rest said nothing about it. UPDATE MEMFUN * Proposal: Change to "replace". * Rationale: It more faithfully describes the semantics of the operation. One reviewer in favor (Dave), plus Pavel and myself. HEADER ORGANIZATION * Proposal: follow a fine-grained policy, possibly with "grouping" headers (e.g. for key extractors.) * Rationale: Seems like good style. Two reviewers favored this approach (Dave, Gary). The rest didn't care/say anything. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

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

01 Apr '04

Hi Fredrik, thank you for the reviewing effort! ----- Mensaje original ----- De: Fredrik Blomqvist <fredrik_blomqvist(a)home.se> Fecha: Martes, Marzo 30, 2004 11:40 pm Asunto: [boost] Re: Formal Review: Indexed Set [...] > * What is your evaluation of the design? > I don't feel quite comfortable with the assymetry of index-0 not > needing a > get<> accessor. I'd prefer forcing the use of get<> everywhere but > I guess I > can live with it if thats decided. More real-world usage should reveal > wether a substantional amount of use-cases naturally benefit from > this bias. Others have also expressed dislike for this feature. Admittedly, it is easier to go the other way around: releasing first without default get<0> and gaining experience to see if it's worth adding on a later release. OTOH, I find the feature useful... I don't know. > > I also second the requests for lifting an implementation of a > bidirectional_map/set to official status. But I don't expect nor > demand this > to be added before acceptance, I'm fine with it being a reasonable > prioritized roadmap feature. Count on it. I'm emotionally attached to bimap, as this container was that started it all. > > Serialization support is also high on my wish-list (but with same > remarks as > above). It is already in the todo list. I'll try to reserve some time to enter into the serialization review and use this case as a testbed. > * What is your evaluation of the implementation? [...] > -I think it would be better if the iterators (index_iterator.hpp) were > generated using boost.iterator_facade/adapter instead of the > boost.operatorshelper. This would make it easier to adapt and for > example directly support > the new iterator concepts. Ummm... will look at it. > -This is more of a "feeling", but could perhaps (parts of?) the > 'member'functionality be refactored to use boost::bind/mem_fn code > instead? I don't think so. member<> and the other key extractors are polymorhic, meaning that they accept not only objects of type T, but also reference_wrapper<T>'s, pointers to T and some more. I cannot figure out how to do this with boost::bind. > * What is your evaluation of the documentation? [...] > Some nitpicks: > -In the example at the end of the tutorials section ('Projection of > iterators') > I think it would be clearer if it would use equal_range instead. You cannot! I was bitten by this at my first try to write the snippet. Suppose we do an equal_range() on "sister" and get the range [it0,it1): it0 will point to a sister and *it1 will point one-past the last occurrence of "sister". Imagine now that we are prepending "younger" instead of "older" and that *it1 is "zoe". Then while(it0!=it1;++it0) { // get it2 from it0 by means of project() tc.insert(it2,"younger"); } kah-boom! Now, *as seen by index #1*, "younger" gets between the last occurrence of "sister" and "zoe" (alphabetical order). So it1 will be pointing off beyond the "sister" range (in fact, an infinite recursion ensues.) I could have fixed this by considering (--it1) instead, but I thought the way I settled on was clearer for explanatory purposes. > > -I find the coding style to be slightly too compact. No space > after ',' and > '&' etc makes it more difficult to quickly browse. Why not just > follow the > semi-official boost coding guidelines? (currently found in the > file area) No particular reason for the style, I've been coding like this for 10 yrs. Other reviewer requested that lines did not exceed 80 chars, which I've just done. But inserting the missing blanks is a pain in the ass, and I'll probably start coding again like before as soon as I forget about it. > > -Several of the code example in the tutorial section could be slightly > reformatted to use less horizontal screen space (see for example > the 'Key > extraction' part). > I'd rather scroll vertically than horizontally! Simply pulling in > some of > the end of line comments would fix most of it. > Previously reported request, it's in my todo list. > * What is your evaluation of the potential usefulness of the library? [...] > * Did you try to use the library? With what compiler? Did you [...] > Hope to be able to use it in larger scale shortly. Please do it and report your experience. > * How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? [...] > * Are you knowledgeable about the problem domain? [..] > * Do you think the library should be accepted as a Boost library? > > Yes, I vote for acceptance. Well, thank you! I hope you can find this lib of some use in the future. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Formal Review: Indexed Set
by Pavel Vozenilek 01 Apr '04

01 Apr '04

The review of Indexed Set library, written by Joaquín M López Muñoz starts today (March 20) and runs for 10 days. Latest version (9.4) of the library is available on: http://groups.yahoo.com/group/boost/files/indexed_set.zip (328 kB) What it is? indexed_set is generic, STL compliant container providing one or more views on its data. These views allow to use data sorted according to different criteria. Change in container data is automatically propagated into all views. How many views and what ordering is applied is specified in declarative way, as template parameter. What it is good for? - it can replace multiple collections of data and hand-written code keeping them in sync. - it can replace standard containers (as std::set or std::list) if these may not meet future reqirements. - it can serve as basic for other libraries. For example RTL (relational tables library) may use indexed_set to hold its data. Other features of indexed_set: - sorting can be performed on result of member function (similar to calculated indexes in RDBMS). - indexed_set can be used as 'wrapper' over other data structures, e.g you can see data in std::vector as being sorted in set-like structure (but without structures being synchronized). - many, many others ... Future development: - planned functionality is described on its own page in documentation. - indexed_set may also implement access to its data in the same way as std::deque, with random O(1) access History of the project: - it started as 'bimap' library more than year ago, - some two dozen iterations were released, - several Boost people expressed their interest or did suggest features. Boost-wide reusable parts of the library: - indexed_set includes (nearly verbatim) copy of Andrei Alexandresu ScopeGuard. It is intended as stop-gap until Boost wide library emerges. - maybe auto_space.hpp can be liften into utilities. Portability: - see document page for list of compilers and their issues - Can someone try to run tests under release mode of VC 6.5? We got different results with different machines. Word from the autor: "Thank you for reviewing indexed_set. There are several points, mostly concerning naming, that I'd like to be discussed during the review. You can find these at the URL http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html If you evaluate the library and deem it acceptable for Boost, please walk the extra mile and express your opinions about the issues brought forward in the review notes. Naming issues are quite sensitive, and I'd like to reach as general a consensus as possible." Your review comments are welcomed. Found problems and suggestions for documentation are highly sought. Requests for new features requests may shape way indexed_set will evolve in future. As naming questions can generate lot of mail-list traffic, I'll start separate thread to deal with them. /Pavel

12 36

geometry2d: Whats the status of geometry2d in the boost vault?
by Tom Brinkman 01 Apr '04

01 Apr '04

There is an interesting class on the boost vault called geometry2d. What is the status of this class. Its related to the proposed region class. http://groups.yahoo.com/group/boost/files/geometry2d __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

3 2

[optional] proposal for extension
by JOAQUIN LOPEZ MU?Z 01 Apr '04

01 Apr '04

In the rationale of Boost.Optional, optional<T> is proposed as a convenient replacement of the time-honored practice of returning a std::pair<T,bool> with the bool indicating whether the T object is meaningful or not. Notably, this is precisely what some STL containers' memfuns do. So why not augment optional<T> with the following: optional<T>::optional(std::pair<T,bool> const&); and the obvious semantics? This would allow for instance to use optional<> like this: std::set<int> s; ... boost::optional<int> oi=s.insert(10); // oi is initialized iff insertion took place. Comments? Apologies if this has been discussed previously. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 5

RE: [boost] Re: Region Library?
by Hanson, Iain 01 Apr '04

01 Apr '04

> From: Allan Odgaard [mailto:ML@Top-House.DK] Sent: 30 March 2004 22:25 > > > Yes -- although I personally do need it even when I do not write > operating systems ;) and thus my question really was if there is any > general interest in such a library, since I did exhaustive searching > and was only able to find such region stuff implemented > publicly in the > GDK/GTK library, which is ANSI-C AFAICT, and that led me to the > conclusion that either there is no real use for this stuff > outside GUI > kits, windowing systems, and 2D games or efficient region "logic" is > often skipped for ad hoc workarounds like using bounding boxes or > refreshing more than necessary -- in which case there really ought to > be a library. > I think that there really is a need for such a library. From what I have seen, many libs that need this either use ad hoc solutions as you suggest above, or they re-invent the wheel and the solution they come up with is intimately bound up with their problem space and therefore not easily re-useable. /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. ==============================================================================

2 1

Re: [boost] geometry2d: Whats the status of geometry2d in theboostvault?
by Tom Brinkman 01 Apr '04

01 Apr '04

>> SFINAE makes it possible, and we have something proprietary along these lines here at work. I'd by happy to elaborate more on specific questions if you are interested to know more. Yes, sounds interestion. While I'm sure that your concerns are valid about this library in its current state, i've found this library to be good enough. It may not be perfect, but its a better rectangle class than any i've seen. I think that we should get it reviewed by others and try to get it added to the main boost cvs. When an improved geometry class comes along, we could add that one to boost as well. Geometry2d is not a complicated library, as it consists of only one header file, and would be easy enough to just add it to the utility folder. Just my thoughts, Tom brinkman __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

3 2