- Boost - lists.preview.boost.org

Re: [boost] [BGL] least common ancestor
by Cromwell Enage 02 Apr '04

02 Apr '04

Walter Landry <wlandry(a)ucsd.edu> wrote: > Hmm. I don't know if I'm that patient. How about > _I_ convert it to C++, and then you can Boostify it? Okey-dokey! There's a subdirectory in the File Vault called "bgl_algo", you can upload it in there so I can find it easily. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

RE: [boost] Re: Policy or Trait?
by Reece Dunn 02 Apr '04

02 Apr '04

David Abrahams writes: >I think your definitions are mostly on target, but I think where you >go wrong is that traits/policies has less to do with how a template >is defined than how it's used. To me a traits class provides information to a template class that gives (possibly platform or type dependant) information. For example, the decimal point character (100.00 or 100,00?) would be in a traits class (I know this is in a locale, but this is an example). Another example would be a format string to use as a separator between items in a list, depending on whether a character, string, wide character, wide string, etc are used. A policy class provides functional, i.e. behavioural, information. Examples include string comparison, pointer validation (for smart pointers) and error handling (e.g. smart pointers and how to handle InvalidPointer - nothing, throw std::exception, assert failure, etc.). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

RE: [boost] Policy or Trait?
by Rozental, Gennadiy 02 Apr '04

02 Apr '04

> Trait - A class template parameterized on a single type that > associates information with that type. A traits class, > therefore, provides an external, named grouping of > metainformation, behavior, or both for that type. A trait > class is never passed as a template parameter; it's name is > ubiquitous. A traits class never has state. By state you mean non-static data members, yes? > Policy - A class template passed to other templates for the > purpose of providing a named grouping of metainformation, > behavior, or both to those templates. Because it is a > template parameter, different policy classes can be used as > desired. In many cases, a policy class is used as a base class. Well, apparently there is somebody who think the same as I do. Thank you Rob, for your definitions. They seems sound and close to what I have in mind. > What do you think? I know that my definitions mean that > std::char_traits is a policy class, despite its name, and > they probably deviate from some other ad hoc definitions. > The question is whether these provide sound, distinct, and > defensible concepts that could be codified for future use at > Boost (and elsewhere). That's flaw in char_traits not in definitions above, IMO. Gennadiy.

2 1

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

Re: [BGL] forced client complexity
by Vesa Karvonen 02 Apr '04

02 Apr '04

Provisional Dissonance: >What I was looking for, really, was dialog on existing design >strategies. It sounds like your issues with property maps mirror my >confusion with the library design, though. While I can fully appreciate >the desire to write generic code, it feels like BGL has pushed the >complexity of creating and enforcing coupling between the generic >graph/node/visitor/algorithm/etc onto the client. [...] A graph algorithm must be able to associate information on the elements of the graph. For instance, depth-first search needs to know whether it has already discovered a specific node or not (and more). In the graph utilities we implemented as part of a school project in Java, we basically relied on the hashCode() and equals() methods that every Java Object provides. The algorithm templates then internally use HashMaps for associating information on node and edge objects. This means that each time an algorithm needs to access some information (that the algorithm requires internally) on a node, a hash table lookup is performed. Assuming a good hash function, hash table lookups are O(1), but they are still slower than a direct array accesses, or accessing a member of a structure. The design employed by BGL makes it possible to provide faster lookups than what is possible with hash tables. The cost is, as you have noticed, tougher requirements for the client. [...] >If, instead, it is a synthesized construct for communication between a >graph and the algorithm operating over it, why should the client be >responsible for its maintenance instead of the framework? What are the >advantages of this approach? The advantage is that the client can choose how nodes are mapped to indices. The client can, in particular, provide a significantly faster mapping method. For example, the color of a node could be stored in the node itself, which would mean that accessing the color property would be a very fast O(1) operation. It could easily be an order of magnitude faster than a hash table lookup. >What are the disadvantages of simplifying things for the client? The minimal information needed by graph algorithms, assuming best asymptotic complexity guarantees are desired, is that the client provides hashing and equality comparison functions for nodes and edges. The disadvantage of requiring only hashing and equality comparison from the client is that sometimes there are significantly more efficient ways to associate information with nodes and the opportunity to take advantage of those more efficient ways is lost. It should also be possible for a graph algorithm to internally convert a graph to an isomorphic copy that allows essentially optimal accesses (it should be doable in O(V+E) time and space in most cases). However, the time and space required by the conversion would probably make such a conversion useless except for graph algorithms whose complexity is significantly higher than O(V+E). >This is the type of design issue that I intended to question with my >initial post. Does this answer your question? Regards, Vesa Karvonen _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

1 0

[ublas] Patch to triangular.hpp
by Giovanni Bajo 02 Apr '04

02 Apr '04

Hello, the attacched patch fixes a compilation problem of uBLAS with GCC 3.4. The fix looks legit to me, but I cannot assure this won't break other compilers due to bugs. Maybe you can monitor closely the regression fixes after having applied this. OK to commit to HEAD? -- Giovanni Bajo begin 666 triangular_gcc34.txt M26YD97@Z('1R:6%N9W5L87(N:'!P#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M#0I20U,@9FEL93H@+V-V<W)O;W0O8F]O<W0O8F]O<W0O8F]O<W0O;G5M97)I M8R]U8FQA<R]T<FEA;F=U;&%R+FAP<"QV#0IR971R:65V:6YG(')E=FES:6]N M(#$N,3@-"F1I9F8@+74@+7<@+6(@+7(Q+C$X('1R:6%N9W5L87(N:'!P#0HM M+2T@=')I86YG=6QA<BYH<' ),C@@3F]V(#(P,#,@,#<Z-3@Z-3<@+3 P,# ) M,2XQ. T**RLK('1R:6%N9W5L87(N:'!P"3(@07!R(#(P,#0@,3$Z,#$Z,#(@ M+3 P,# -"D! ("TY-3@L,3 @*SDU."PQ,"! 0 T*( T*(" @("!T96UP;&%T M93QC;&%S<R!4+"!C;&%S<R!&,2P@8VQA<W,@1C(L(&-L87-S($$^#0H@(" @ M('1Y<&5N86UE('1R:6%N9W5L87)?;6%T<FEX/%0L($8Q+"!&,BP(a)03XZ.G9A M;'5E7W1Y<&4@=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R+"!!/CHZ>F5R M;U\@/0T*+2 @(" @(" @=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R+"!! M/CHZ=F%L=65?='EP92 H*3L-"BL@(" @(" @('1Y<&5N86UE('1R:6%N9W5L M87)?;6%T<FEX/%0L($8Q+"!&,BP(a)03XZ.G9A;'5E7W1Y<&4@*"D[#0H@(" @ M('1E;7!L871E/&-L87-S(%0L(&-L87-S($8Q+"!C;&%S<R!&,BP@8VQA<W,@ M03X-"B @(" @='EP96YA;64@=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R M+"!!/CHZ=F%L=65?='EP92!T<FEA;F=U;&%R7VUA=')I>#Q4+"!&,2P@1C(L M($$^.CIO;F5?(#T-"BT@(" @(" @('1R:6%N9W5L87)?;6%T<FEX/%0L($8Q M+"!&,BP(a)03XZ.G9A;'5E7W1Y<&4(a)*#$I.PT**R @(" @(" @='EP96YA;64@ M=')I86YG=6QA<E]M871R:7@\5"P@1C$L($8R+"!!/CHZ=F%L=65?='EP92 H M,2D[#0H@#0H@(" @("\O(%1R:6%N9W5L87(@;6%T<FEX(&%D87!T;W(@8VQA E<W,-"B @(" @=&5M<&QA=&4\8VQA<W,@32P@8VQA<W,@1CX-"@`` ` end

1 0

RE: [boost] Re: Policy or Trait?
by Hurd, Matthew 02 Apr '04

02 Apr '04

> On Behalf Of E. Gladyshev > Sent: Friday, 2 April 2004 1:34 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Policy or Trait? > > > From: "Hurd, Matthew" <hurdm(a)sig.com> > > [...] > > It would be nice if something new like "aspect class" or some such could > > Interesting name! I second your opinion in many ways. Would be nice to stop the confusion / confounding by describing somewhat rigorously a classification / nomenclature for "aspect classes". Constant aspects (bad name?, plain? simpleton?) - static constants and types only (bad name) Static aspect - constant aspect extended to include static methods Base aspect - intended to be inherited from by a client aka common MCD policy class - policy aspect perhaps? Chain aspect - not sure how to describe this Recurring base aspect - a base aspect that requires the first parameter to be the client class, this is the CRTP. Generic "blah" aspect - "blah" parameterised by additional template parameters beyond the client e.g. generic recurring base aspect is the CRTP with additional params A generic base aspect class would describe much of the MCD style policy classes. A static aspect could be used in a base aspect like manner or without the inheritance. "Aspect" might be inappropriate as I'm not 100% on my AOP nomenclature, but it feels appropriate. A trait or policy could be classified in such terms which might avoid some confusion. Needs some work, but it might start something... > I don't think that differentiating between traits and policy > makes too much sense or really necessary. > As for now to me, they both are parts of the same concept. > The idea is that a class can define an API > specification. The user is responsible > for implementing the API and supplying the implementation > to the class as a template parameter. > > Traditionally an API is not a set of just behaviors > or just data structures. It is a combination of both > and it doesn't have to be stateless. > > So what's so unique about API's from the OOP standpoint > especially. Well, an API as such cannot be > INSTANTIATED. It just EXISTs as a set of rules, etc. > It is like namespaces in C++. > You cannot instantiate a namespace! > You can instantiate data types defined by the API though. > > So to me, both traits and policies are sort of > interchangeable namespaces. > Perhaps my view is too simplistic. > > I sometimes do something like this > > template< typename MatrixApi > > struct equation_system_solver {...}; > > struct api > { > private: //** note private here > api(); > }; > > struct my_vector_api : api {...}; > > template< typename VectrorApi > > struct my_matrix_api : api {...}; > > equation_system_solver< my_matrix_api<my_vector_api> > s; Interesting. Especially handy I'd imagine if you use the CRTP with the api to give yourself some static polymorphism. Another pattern trait / policy style pattern I've used recently is having integer offsets and types associated with names in a type that represents a packet type, these "aspect classes" are combined with a packet type in a client to handle different financial exchanges in my case. This would be a "constant aspect" in my nomenclature above. It is a trait of a concept rather being a trait of a specific type or class. Gets interesting when one of those types in the constant aspect is a static aspect that describes operations on the type to be found at the offset indicated. The packet aspect is really nothing much more than a bunch integers and associated types and it feels like a trait (it is a trait of a concept); it is used like a policy. $0.002 Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

RE: [boost] Re: Policy or Trait?
by Hurd, Matthew 02 Apr '04

02 Apr '04

> On Behalf Of David Bergman > Sent: Friday, 2 April 2004 2:37 PM > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: Policy or Trait? > > I wrote: > > > So, for me it is pretty easy, traits *only* describes > > Model-invariant parts of Concept Features while policies > > furnish Models of Concepts. > > Skipping all the GP stuff: traits DESCRIBE and policies ACT. Nice and simple. Gennadiy Rozental disagrees though. He gives the example of how to print something as a trait but this acts. A type in a trait could also be a description or reference of an action to take even more indirectly. To me the description of the action and the action is not clear cut. When describing the action is a level of indirection really necessary to make it a trait? I can see both cases... Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

[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

Re: [boost] [BGL] least common ancestor
by Cromwell Enage 02 Apr '04

02 Apr '04

Hellow, there. > Does anyone have an implementation of least common > ancestor (LCA) for the graph library? I could hack > something together to fit my needs, but it would be > nice if someone already did the work for me. I did a Java implementation a while back, if you're patient I'll convert it to C++, Boostify it, and put it in the Yahoogroups File Vault. > Thanks, > Walter Landry You're welcome. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

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

problem with global mutex object on windows
by Stefan Seefeld 01 Apr '04

01 Apr '04

hi there, we'v run into a problem with the boost_thread mutex class, when used as a global object. Imagine a singleton class as class Singleton { public: static Singleton *GetInstance(); static void Destroy(); private: struct Guard { ~Guard() { Singleton::Destroy();} }; static Singleton *instance; static Guard guard; static boost::mutex mutex; }; where the internal access to 'instance' is serialized by means of the mutex (inside methods GetInstance() and Destroy()). It is the Singleton::Guard destructor that is responsible to free the instance (if it isn't destructed already). It, too, uses the mutex to protect access. In a specific context on windows xp it happened that the mutex variable was destructed before the guard, leading to a global application lock-up when the Singleton::Destroy() (called from the guard destructor) attempts to aquire the lock. Is there a way around this dilemma ? During debugging I set the 'm_mutex' member of the mutex class (which is a CRITICAL_SECTION) to zero right after deletion, which worked, i.e. there was no lock-up. I'm not sure though that this is the correct thing to do. Any suggestions ? Thanks, Stefan

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

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

01 Apr '04

> From: Fernando Cacciola [mailto:fernando_cacciola@hotmail.com] > Sent: 01 April 2004 17:18 > > > "Hanson, Iain" <iain.hanson(a)csfb.com> escribió en el mensaje > news:4DC0299EAC0ED311B7580090274CF0640B690B1C@slon12306.csfp.co.uk... > > [ snip ] > Though I would certainly found such a class useful, I'm not > sure if its > place is Boost. > Seems too domain-specific to me. > Why not sourceforge, or maybe flipCode or any of the more > game/graphics-centric repositories. Unfortunately, most of them don't write generic code and I think that you are being a little pessermistic with regard to applicable domains. However, even if this was their only domain of applicableity, I'm not sure that it is any more restrictive than octonion & quaterion that are already in boost. /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

[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

C++ subranges
by Brian Martin 01 Apr '04

01 Apr '04

Hi Brian Martin wrote: > I have a suggestion for a simple Boost feature - subranges. [...] > The big question is, do any of you think this is a useful enough feature? Maciej Sobczak wrote: >Yes, it is. >What's more, the biggest gain (in my humble opinion, of course) is not >the bare fact that you can have range checking at run-time, but that it >is possible to provide range checking at *compile-time*, thus >strengthening the type system. There are some interesting ideas in your code. The current version of my subrange class does not trap potential compile time errors. Your technique of using template specialisation for this is a good idea but unfortunately the following gets past my (Borland) compiler: range<0, 200> k4(500); and it would be nice to catch this. Also, I don't see how the following can ever be trapped by a compiler: range<0, 100> i(4); i = 98; i++; ++i; surely that is a runtime thing. One possible idea for catching the first one is to redefine the template as follows: template <long L, long U, long V> class range { long v_; public: range() { static_assert<L <= V && V < U>(); v_ = V; } }; I've tried this on a simple example and it seems to work. Unfortunately, what you pass to V has to be a constant expression. Thus this won't compile at all: const long x = 2; range<0, 10, x> my_range; Even though x is in range and const. I suppose it's a const "variable". Drat. Your class doesn't have the concept of a "base type". It's a template restricted to longs. Class subrange allows restriction of any type that supports the appropriate numerical operators (even classes - admittedly a bit dubious). This is similar to the Pascal facility where you can have subranges on any ordinal type (i.e. integral numerical, character or enumeration) e.g. type LowerCaseChar = 'a'..'z'; type UpperCaseChar = 'A'..'Z'; type DaysOfTheWeek = (Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday); // equal to a C++ enum declaration type WorkingDay = Monday..Friday; // For those who don't work weekends! I know that C++ does implicit conversions from say char to int etc. e.g. typedef range<'a', 'z'> lowercase_char; but typedef subrange<char, 'a', 'z'> lowercase_char; is a bit more "self documenting". The specification of the base type char makes it clear we're storing characters and not longs. I'll have another think about some of the compile time check issues. Regards, Brian Martin _______________________________________________ Unsubscribe & other changes: <http://lists.boost.org/mailman/listinfo.cgi/boost>

1 0

C++ subranges
by Brian Martin 01 Apr '04

01 Apr '04

I have a suggestion for a simple Boost feature - subranges. For those of you who may not know, subranges are a Pascal idea. Using un-restricted numeric types such as ints, shorts and floating point types is somewhat dangerous. For example, if you write a function that, given a date, returns the number of the day in the year that date falls on, what type do you return? Most C/C++ programmers would automatically use an int but ints can be negative and -1 as a day of the year is meaningless. So use unsigned types. But then 0 is invalid, as is any value above 365. Subranges to the rescue... In pascal one would write type DayOfYear = 1..365; function NthDayOfYear(const d : Date) : DayOfYear; The type statement declares a new data type that is restricted to the range 1 to 365 and this is used as the return type of the function. If NthDayOfYear has a fault that sometimes generates a value outside this range, you'll get a runtime error. The idea is to have range checking switched on during development, but to switch if off for release code for efficiency reasons, something that all good pascal compilers can do. My own personal experience having used pascal type languages with this feature is that it's very, very useful indeed. On a number of projects, subranges have illuminated obscure bugs in my code that I might otherwise have missed. After having switched to C++ from Pascal, I soon found myself missing subranges so I wrote a class template that emulates them: template <typename T, T min, T max> class subrange; This would contain the usual operators/constructors etc. that I've omitted for shortness. The above example would now become in C++: typedef subrange<int, 1, 365> day_of_year; day_of_year NthDayOfYear(const Date& d); The class is very simple - all it does is store a value and then checks to make sure it's always in the range min to max when you assign variables of type T to it, do arithmetic and so on and throws an exception if the new value is out of range. A preprocessor symbol is used to switch this range checking on or off as required so that you can release code without the checking overhead. The big question is, do any of you think this is a useful enough feature? Regards, Brian

2 1

Service Pack 6 for Visual Studio 6.0 released
by Bronek Kozicki 01 Apr '04

01 Apr '04

Relevant Knowledge Base article with list of fixes is here http://support.microsoft.com/default.aspx?scid=kb;en-us;834001 Actual download (63MB) is here http://www.microsoft.com/downloads/details.aspx?FamilyId=A8494EDB-2E89-4676… I though that Boost.Python users might be interested B.

3 6

simplifying library install names
by Benjamin Kosnik 01 Apr '04

01 Apr '04

When I build boost-1.31.0, like so: bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.2 -sTOOLS=gcc -sBUILD=release --prefix=/usr I end up with a bunch of oddly-named library files: libboost_filesystem-gcc-1_31.a libboost_filesystem-gcc-1_31.so.1.31.0* libboost_filesystem-gcc.a libboost_filesystem-gcc.so* is there a way to run bjam or configure the build process so I get something sensible, like: libboost_filesystem.a libboost_filesystem.so.1.31.0 libboost_filesystem.so (symlink) ? best, benjamin

2 2

BGL least common ancestor
by Walter Landry 01 Apr '04

01 Apr '04

Greetings, Does anyone have an implementation of least common ancestor (LCA) for the graph library? I could hack something together to fit my needs, but it would be nice if someone already did the work for me. Thanks, Walter Landry wlandry(a)ucsd.edu

1 0

Region Library?
by Allan Odgaard 31 Mar '04

31 Mar '04

A region is used as the term to describe a set of rectangles -- e.g. could be as simple as std::vector<rectangle>. When working with regions, one often needs to perform various operations like finding the intersection of two regions, the union, subtract one region from another or xor two regions (which is the union minus the intersection). I would like to know if there is a) any interest in such a library and/or b) if such a library already exists? I figure the usefulness of such a library mostly has to do with optimizing (and clipping) refresh in a graphical view port, which is often something the operating system takes care of. And thus user code rarely has to deal with these things.

4 6

Re:[boost] Serialization: versioning and XML.
by Robert Ramey 31 Mar '04

31 Mar '04

Anatoli Tubman wrote: >My boss just gave me OK to discuss this, so here goes. >A common drawback of various serialization libraries is the need to >provide versioning code for each data structure to be serialized. This >need not be the case for XML archives (and other formats that store >NVPs). Because the program knows which data members it needs, and >the names are stored in the archive, the program can leave any missing >members in their current state (typically just after construction) and >ignore any extra ones. After all, this is one of the ideas behind XML! >More often than not this tactic is sufficient to handle versioning. When >it's not, there's always the old way of explicit version checks. The included XML archive presumes that saving and loading of class variables are synchronized. This is consistent with all the the other archives so that once the serialization for a class is specified it is guaranteed to work with all archives with no code changes. >It seems that this should be easy to implement for boost::serialization. It might be make an archive which implements XML archive in a different way so that data members would be optional and in an arbitrary sequence. Clearly it would be less efficient than the current version and its not clear whether it would be easy or hard to do. Its probably harder than it would first appear. (as most things are). >Just make two passes through the deserialization function. In the first >pass, just collect information on data members to be deserialized into >some kind of map keyed on tag. In the second pass, perform actual >deserialization, looking at the map built in the first pass. Any tags >in the archive but not in the map are ignored together with their >contents. This method would destroy the independence between class serialization specification and archive format. If I were going to do such a thing (which I'm not), I would build this logic into a new XML archive class. You're free to do this. (if your boss will give you permission) Of course, if such an archive can't made, there would be no motivation to use the serialization library at all for this purpose. Actually this question touches upon a central issue about what serialization is all about and how it conflicts with what XML is all about. Serialization is about making an arbitrary set of data structures moveable from one context to another. The serialized data stream is a function of the data structures to be moved. That is, program code => XML definition. The main attraction of serialization is that the code which saves/loads data streams is automatically generated and kept in sync with program data structures. In the XML archive, XML data definition is driven by the program code and data structures. XML is about rendering data in a program independent manner. Program code is synchronized to match the XML structure. That is, XML definition => program code. There are packages that, given and XML definition, will generate C++ code to save/load data as an XML structure. In essence, these packages are the mirror image of serialization. So the question really is: Which is the independent variable? Program code and data structures or the XML definition?. If it's the former serialization to XML archives is a good choice. If it's the latter, a different approach would probably be better. As long as code and XML definition doesn't change, It doesn't make much difference. When something has to change the question arises, do we change he XML and adjust the program to match or vice versa? This question also touches on another topic that comes up regularly. There is often a desire to use the serialization library to generate a specific data format. If this format is a meta-data specification such as XML it's possible. If it's a more specific format - serialization is probably not the right approach. Again the question comes down to who's boss. Is the data stream format driving the program design or vice versa. With the serialization library, data stream format is driven by the program data structures. Attempts to mandate a too specific data stream format may be possible but ultimately not worthwhile. Robert Ramey

2 1

Re: [boost] [BGL] forced client complexity
by Cromwell Enage 31 Mar '04

31 Mar '04

Hello, prs. I'll be happy to discuss the complexity of the Boost Graph Library with you in the boost-users mailing list (as soon as I rejoin it). Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

1 0

Using bcp
by Edward Diener 31 Mar '04

31 Mar '04

If the --boost=path is not used when executing bcp, how does bcp know where the beginning of the Boost tree is ? If I execute bcp from within the Boost tree without specifying --boost=path, does it work by scanning down through the directory structure from the current directory ? I think such info should be in the bcp docs.

2 1

patch for boost/config/compiler/gcc.hpp
by Benjamin Kosnik 31 Mar '04

31 Mar '04

Any chance this could be applied? best, benjamin

2 1

Serialization: versioning and XML.
by Anatoli Tubman 31 Mar '04

31 Mar '04

My boss just gave me OK to discuss this, so here goes. Please excuse me if it has been brought up before. Please excuse me also if what follows is just downright stupid. A common drawback of various serialization libraries is the need to provide versioning code for each data structure to be serialized. This need not be the case for XML archives (and other formats that store NVPs). Because the program knows which data members it needs, and the names are stored in the archive, the program can leave any missing members in their current state (typically just after construction) and ignore any extra ones. After all, this is one of the ideas behind XML! More often than not this tactic is sufficient to handle versioning. When it's not, there's always the old way of explicit version checks. It seems that this should be easy to implement for boost::serialization. Just make two passes through the deserialization function. In the first pass, just collect information on data members to be deserialized into some kind of map keyed on tag. In the second pass, perform actual deserialization, looking at the map built in the first pass. Any tags in the archive but not in the map are ignored together with their contents. I'm not sure whether current serialization syntax can or should be used with this functionality. Best of luck, -- Anatoli Tubman PTC Israel (Haifa) Tel. (+972) 4-8550035 ext. 229

1 0

[BGL] separate mailing list for boost/graph?
by Jeremy Siek 31 Mar '04

31 Mar '04

Hi All, I just received a request for a separate mailing list for development work on boost/graph. I'm curious as to how many people would be interested in such a list. Please send email to *me* if you have a preference for discussing BGL on a separate list or on the main boost list. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington Graduating in August 2004 and looking for work C++ Booster (http://www.boost.org) _______________________________________________

1 0

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

31 Mar '04

----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Domingo, Marzo 28, 2004 3:28 pm Asunto: [boost] Re: Formal Review: Indexed Set > Hi Joaquin, > > Sorry for joining this discussion so late, but here are my comments: Hello Arkadiy, thanks for joining in. I was certainly waiting for you to show up. > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > > The code looks clean. One minor question: the index class template's > equal_range method forwards to lower/upper_bound. Is it really > the best you > can achieve here or is it just a temporary shortcut? Well, there's some room for improvement. Pavel touched on this issue some time ago, too. I didn't optimize the code at the time cause (1) this is how other STL implementations do it anyway and (2) the gain is not that much. But consider this QoI detail in my todo list. [...] > - Do you think the library should be accepted as a Boost library? > > Yes, definitely. Definitely thank you :) I'm glad you like the library. Maybe you have still some spare time to take a look at the review notes and state your opinions on best namings and header organization for indexed_set. Once fixed, there's no way back and we'll have to live with whatever cool/ugly names we have settled on. Two more questions: * Have you looked at mpl_index_list? This facility was designed with RTL in mind so as to ease the internal creation of indexed_set instantiations. Useful for your particular needs? * (off-topic) How's the RTL stuff going on? Planning on open some public discussion on its design aspects? I'd certainly love to contibute in that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost-1.31.0 def() and VC7.1.3088 strangeness
by Peter Hornby 31 Mar '04

31 Mar '04

Hi, The boost version is the Version_1_31_0 tag from the CVS repository. The VC version is 7.1.3088. Compiling foo.cpp (attached) results in the error reported in BuildLog.htm (attached). The VC options are also in the BuildLog.htm Uncommenting the line in foo.cpp that that begs you to, results in a clean compile. Has anybody else encountered this sort of weirdness?? I'm getting a lot of related behaviour, but this one is simple. #include <boost/python.hpp> using namespace boost::python; class World { public: World(std::string msg): msg(msg) {} // added constructor void set1(std::string msg) throw(std::exception) { this->msg = msg; } void set2(std::string msg) { this->msg = msg; } private: std::string msg; }; void wrap_World(class_<World> &foobar) { // foobar.def("set2", &World::set2); // OK, uncomment this and the compilation works!! foobar.def("set1", &World::set1); // Error on VC7.1 }

2 3

Boost.Python interpreter reinitialization problem
by Maciej Sobczak 31 Mar '04

31 Mar '04

Hi, We (the shop where I try to promote Boost) are using Boost 1.30.2 and currently the main focus is on interpreter embedding with Boost.Python. I've hit a hard problem with this library. For some reason, I would like to clean up the Python interpreter after performing some coputations with it and possibly reinitialize it later, if there is again a need to do some scripting. In other words, my use of Python interpreter is tightly scoped and there are repetitive calls to Py_Initialize() and Py_Finalize() functions during the lifetime of the application. The problem is that the initialization code that executes inside the BOOST_PYTHON_MODULE block (more specifically: the class_'s "definitions") throws when execituting for a second time: "trying to register to_python_converter for a type which already has a registered to_python_converter" This code is executed as a result of "from mymodule import *" Python command; the second execution is a result of running this command in the interpreter that was already finalized and RE-initialized. Is there a way to re-initialize the module without re-registering the converters? Hacking the Boost.Python library is a valid option, but I would need at least a suggestion where should I go. Thank you very much for your time, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

2 1

Re: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > What about when you use boost::policy::errormsg_storage instead of > > boost::policy::no_errormsg_storage? Doing this allows the following: > > > > typedef boost::errorcheck< boost::policy::error_storage<>, > > boost::policy::errormsg_storage > > > errorcheckmsg; > > > > try > > { > > errorcheckmsg em; > > em( "oops!" ) = -3; // note the special syntax > > } > > catch( errorcheckmsg em ) > > { > > std::cout << "error: " << em.get_msg() << '\n'; > > } > > > > resulting in "error: oops!" being outputted. Using your method, the >message > > string will ont be passed and thus you would get "error: unspecified >error"! > > That is why I implemented it as above. > >I didn't see anything like that in the code you showed. It was >probably in the full implementation, but I was only looking at >what's quoted above. I posted it as a different message (errorcheck) and have been revising it based on comments and suggestions. The full code is attached here. >Anyway, why must either constructor manage the string at this >point? Why wouldn't the generation of the string occur at the >time it is requested? That is, there is no string to copy if >there is no string generated until the get_msg() mf is called. >That mf can create the string (reusing it if already computed, of >course). It depends on what you are using it for. The string for the errno handler *is* generated at get_msg() call-time. The above is based on an example Volodya posted where he put the name of the function he was calling into the code. E.g. // [paraphrased]: if( ::read( fn, ... ) < 0 ) report_error( "read", errno ); becomes ec( "read" ) = ::read( fn, ... ); As another example, you could have a handler that supports windows GetLastError and do something like: try { winerr( "Rectangle" ) = ::Rectangle( hDC, 10, 10, 110, 110 ); winerr( "Ellipse" ) = ::Ellipse( hDC, 10, 10, 110, 110 ); } catch( winapi_errorcheck e ) { std::cout << "error: " << e.get_msg() << " - " << e.error_string() << '\n'; } NOTE: I know that mixing GUI/console does not work -- this is just a usage demonstration. >If you find your approach is still needed, no problem. I just >wanted to be sure you understood what I had implied. No worries. I understood your approach, but I was designing it to be as flexible as possible. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Building bcp with Jam V2 and como
by Edward Diener 30 Mar '04

30 Mar '04

I attempted to build bcp with Jam V2 and como under Win2k with the latest CVS source and the latest bjam.exe. My como installation is in H:\Utilities\Comeau directory and is already set up to use a back end compiler. I executed: bjam --v2 -sCOMO_PATH=H:\Utilities\Comeau -sTOOLS=como from the boost\tools\bcp directory and received this output indicating an error: "H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/util\order.jam:38:in loaderror: no native rule "add-pair" defined in module "class@order." H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/tools\unix.jam:16:in load H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\toolset.jam:259: in toolset.inherit H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/tools\gcc.jam:19: in load H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import..\..\project-root.jam:2: in modules.load H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\project-roots.jam:160: in object(project-root-object)(a)1.initialize H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\project-roots.jam:52: in project-roots.load H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\project.jam:61: in project.load H:/Programming/Version Control/CVS/Home/boost/tools/build/v2\build-system.jam:75: in load H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel/bootstrap.jam:120: in boost-build H:\Programming\Version Control\CVS\Home\boost\boost-build.jam:12: in module scope" What am I missing or what did I do wrong ? Finally it would be nice if Boost could distribute some batch files ( or Unix shells ) for each compiler toolset in which all the builder would have to do is to enter the mandatory information, as optional arguments since the environment variable might be already set, for that toolset in order to trigger off the build, rather than have to worry about command line arguments. I know the command line isn't complicated but anything to simplify the end user's or developer's burden in using Boost Build would get my vote. I have no doubt it is an excellent system, but it is a bear to learn, when all one wants is to simply build portions of Boost. I know this sounds lazy but then I am a very lazy programmer in all but programming and documentation where I am just mildly lazy <g> .

4 8

Re: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > The errorcheck class now has a policy-based implementation, so it would >look > > something like: > > > > template< typename ErrorStorage, typename ErrorMsgStorage > > > class errorcheck: public Storage, public MsgStorage > > { > > private: > > inline errorcheck( const Storage & s, const MsgStorage & ms ): > > Storage( s ), MsgStorage( ms ) > > { > > } > > public: > > inline errorcheck( typename Storage::error_type e ): > > Storage( e ), MsgStorage() > > { > > if( failed()) > > throw( errorcheck< Storage, MsgStorage >( *this, *this >)); > > } > > }; > > > > which, IMHO, is more confusing than the straight throw( *this ), but >does > > not use the copy constructor, relying instead of the fully constructed > > Storage and MsgStorage base classes. > >I wouldn't call it confusing, though I'd expect that you'd need >to document why you couldn't do the more obvious thing. I mean confusing in that you have errorcheck( *this, *this ) so it is harder to see what is going on. I have added a comment line explaining why this is done and would also put this in the docs. >I do have to ask why the private ctor takes a MsgStorage object >to copy since the MsgStorage in this case will be the default >constructed base subobject created in the initializer list of the >throwing ctor. As written, the second argument to that ctor is >useless; the private ctor could default construct its MsgStorage >subobject. >Actually, though, I had this in mind: >template <typename ES, typename MS> >class error_check : public ES, public MS >{ > error_check(typename ES::error_type e, std::nothrow_t) > : ES(e) > { > } > >public: > error_check(typename ES::error_type e) > : ES(e) > { > if (failed()) > { > throw error_check<ES,MS>(e, nothrow); > } > } >}; What about when you use boost::policy::errormsg_storage instead of boost::policy::no_errormsg_storage? Doing this allows the following: typedef boost::errorcheck< boost::policy::error_storage<>, boost::policy::errormsg_storage > errorcheckmsg; try { errorcheckmsg em; em( "oops!" ) = -3; // note the special syntax } catch( errorcheckmsg em ) { std::cout << "error: " << em.get_msg() << '\n'; } resulting in "error: oops!" being outputted. Using your method, the message string will ont be passed and thus you would get "error: unspecified error"! That is why I implemented it as above. >(Note that you used "Storage" where you should have used >"ErrorStorage" in the excerpt above. I just used abbreviations.) That was my bad: ErrorStorage and Storage are the same. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: [boost] Re: IndexedSet Review: unified proposal for naming
by JOAQUIN LOPEZ MU?Z 30 Mar '04

30 Mar '04

----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Martes, Marzo 30, 2004 7:54 pm Asunto: [boost] Re: IndexedSet Review: unified proposal for naming > > "Joaquín Mª López Muñoz" <joaquin(a)tid.es> wrote > > > * Proposal: boost::container::multi_index > > > So far no other library sits in boost::container. > Existing containers probably won't move there > the future (work, compatibility). > Well, I haven't any special desire to move into boost::container, but seems like there's a general consensus that such grand namespaces should begin to emerge. I just have no strong opinion on this, my proposal only meant to collect the feedback gotten from the reviewers. Either way, I think the proposed naming works even without ::container:: Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Any way to speed my use of boost_pp macros?
by Larry Evans 30 Mar '04

30 Mar '04

The file, http://groups.yahoo.com/group/boost/files/managed_ptr/ctor_fwder.zip , shows a simple program using boost/preprocessor macros taking 17secs to execute. If anyone has some suggestions for speeding this up, I'd certainly appreciate it. TIA.

5 14

Re: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

>From: Rob Stewart <stewart(a)sig.com> >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > So the errorcheck object will be in a half-constructed state. That is, >the > > int will be constructed, but the errorcheck object isn't, therefore the > > int's destructor will be called, but errorcheck's deconstructor will >not. > > > > The solution would therefore be to throw an intermediate object, like >the > > Trules from the C++ Templates book by David Vandervoorde and Nico >Josuttis. > > This would then get around the throwing in a constructor problem. >Why not throw a new errorcheck object using a private ctor that >stores but doesn't check the return value? That would work (I realised an implementation after the post). But this is what I was trying to achieve using the copy constructor (and copy assignment), since that copies the object, but does not throw on failure. The errorcheck class now has a policy-based implementation, so it would look something like: template< typename ErrorStorage, typename ErrorMsgStorage > class errorcheck: public Storage, public MsgStorage { private: inline errorcheck( const Storage & s, const MsgStorage & ms ): Storage( s ), MsgStorage( ms ) { } public: inline errorcheck( typename Storage::error_type e ): Storage( e ), MsgStorage() { if( failed()) throw( errorcheck< Storage, MsgStorage >( *this, *this )); } }; which, IMHO, is more confusing than the straight throw( *this ), but does not use the copy constructor, relying instead of the fully constructed Storage and MsgStorage base classes. Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1

RE: [boost] Region Library?
by Powell, Gary 30 Mar '04

30 Mar '04

2D games do this all the time. It's more than a OS problem. -Gary- -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Allan Odgaard Sent: Tuesday, March 30, 2004 11:04 AM To: boost(a)lists.boost.org Subject: [boost] Region Library? A region is used as the term to describe a set of rectangles -- e.g. could be as simple as std::vector<rectangle>. When working with regions, one often needs to perform various operations like finding the intersection of two regions, the union, subtract one region from another or xor two regions (which is the union minus the intersection). I would like to know if there is a) any interest in such a library and/or b) if such a library already exists? I figure the usefulness of such a library mostly has to do with optimizing (and clipping) refresh in a graphical view port, which is often something the operating system takes care of. And thus user code rarely has to deal with these things. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] RE: Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Vladimir Prus wrote: >Reece Dunn wrote: > > >>Yes, you're right. However, there's one additional wish -- I'd like an > >>appraoch different macroses for different functions. E.g. for POSIX >calls > >>I only encounter -1 returns and NULL returns for error reporting. So I'd > >>like > > > >> int tty = check(open(check(ctermid(0)), O_RDRW); > > > >>to work. I guess this could be done by providing two overloads for the > >>'Wrong' function...., but not, the 'Enforcer' template only works for > >>specific type of return value :-( > > > > My errorcheck class (see other posts) has an error policy where you can > > change the fail test. The default is to test errorcode < 0. > >The code you've posted had the check hardcoded, maybe I've missed some >other >post? The error_storage::failed() function has the hard-coded check, but the errorcheck class gets the storage (and check) policy as a template, so you can provide your own class to perform a custom check. > > A current weakness is that it does not return the value passed to it on > > assignment, so you cannot use exactly like the above example. I have >been > > updating it to support errno handling, but this (at present) requires > > something like: > > > > boost::errorcheck< ... > check; > > > > FILE * fp = ::fopen( 0, "r" ); > > check( fp != 0 ); // assert-like syntax > > ::fclose( fp ); > > > > If you are interested, I'll work on supporting constructs like your > > example above. > >I actually wonder if we need a class. Does it have any advantages over >function? E.g: > template<class Checked = default_checker, class T = void> > T check(T t) > { > if (Checker(t)) > throw ... > return t; > } I suppose it comes down to what you are used to and aesthetics. I have been using MS COM objects heavily that rely on HRESULT error code returns, where the code looks like: HRESULT hr; IHTMLStyle * s = 0; if( FAILED( hr = elem -> get_style( &s ))) goto clean; // use the style object clean: if( elem != 0 ) elem -> Release(); if( s != 0 ) s -> Release(); Which is ugly IMHO, so I use a smart pointer for COM object management and have a com::hresult class for storing the HRESULT, mapping it to a string, etc. The errorcheck class is based on a com::result (throwing version of com::hresult) now defined using errorcheck: typedef boost::errorcheck< hresult > result; I suppose there are applications for both approaches, depending on what style you want, what facilities you want, etc. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] Standard C Library and C++ / BOOST
by Klaus Nowikow 30 Mar '04

30 Mar '04

Reece Dunn wrote: [snip] > A trick I use when handling HRESULT error codes is to have a > class like this > (adapted for int error type): > > class errorcheck > { [snip] > public: > inline errorcheck( int ec ): error( ec ) > { > if( ec < 0 ) throw( *this ); > } Careful. Throwing an exception from a constructor means that the object won't be constructed (i. e., does not exist). So you are throwing a non-existing object here. Or am I wrong? Best regards, Klaus

5 8

RE: [boost] Re: Standard C Library and C++ / BOOST
by Klaus Nowikow 30 Mar '04

30 Mar '04

> From: Rene Rivera [mailto:grafik.list@redshift-software.com] > Rob Stewart wrote: > > From: Rene Rivera <grafik.list(a)redshift-software.com> > > > >>Gennaro Prota wrote: > >> > >>>On Sat, 27 Mar 2004 19:23:50 -0500, David Abrahams > >>><dave(a)boost-consulting.com> wrote: > >>> > >>>>"Klaus Nowikow" <nowikow(a)decomsys.com> writes: > >>>> > >>>>>Reece Dunn wrote: > >>>>>[snip] > >>>>> > >>>>> > >>>>>> class errorcheck > >>>>>> { > >>>>> > >>>>>[snip] > >>>>> > >>>>>> public: > >>>>>> inline errorcheck( int ec ): error( ec ) > >>>>>> { > >>>>>> if( ec < 0 ) throw( *this ); > >>>>>> } > >>>>> > >>>>>Careful. Throwing an exception from a constructor > >>>>>means that the object won't be constructed (i. e., does > not exist). > >>>>>So you are throwing a non-existing object here. > >>>>> > >>>>>Or am I wrong? > >>>> > >>>>You're wrong. *this is copied before it is thrown. > Still, the idiom > >>>>above seems a bit suspicious, unless you somehow prevent > derivation > >>> > >>>>from errorcheck. > >>> > >>>I can't believe you are justifying the above. You copy an > object that > >>>doesn't exist yet! (The class is not a POD and has a non trivial > >>>constructor - and even if this wasn't the case...) > >> > >>I don't see how the object is not fully initialized inside > its constructor?? > >>Could you explain your objection? > > > > > > Until the ctor finishes -- after the closing } -- there is no > > object (see 3.8/1). > > Yes the object lifetime hasn't started... but the object is > initialized. Which > according to 12.7 allows for referring to members of the > object directly or > indirectly, in this case by a copy ctor function. I think you are right. When I posted the message above, I didn't take into consideration that the object (*this) is copied before it is thrown. Best regards, Klaus

1 0

Re: [boost] Re: IndexedSet Review
by JOAQUIN LOPEZ MU?Z 30 Mar '04

30 Mar '04

Hi Dave ----- Mensaje original ----- De: "David B. Held" <dheld(a)codelogicconsulting.com> Fecha: Lunes, Marzo 29, 2004 9:57 pm Asunto: [boost] Re: IndexedSet Review > "Joaquín Mª López Muñoz" <joaquin(a)tid.es> wrote in message > news:406802F9.4990B35C@tid.es... > > [...] > > Ummm... If I followed your approach I would be incurring two > > extra copies which is precisely what modify() is meant to avoid. > > For non-destructive updating you can use update(), that's the > > idea. If I'm not making myself clear please tell me so. > > Yeah, I'm not understanding where the extra copies would come > from. As far as I can tell, it's possible to reorder the operations > in modify() without increasing the cost of execution except by a > few instructions. This is my understanding of how modify() works > now: > > mod(element); // changes the element immediately and in-place > unlink(element); // takes the node out of the index > link2(element); // puts it back in at the correct spot Sort of, yes. > > This is what I'm suggesting: > > i = find(new_element); // look to see if modify() can even succeed > if (*i == new_element) return; > mod(element); // now change the node, since modify() will succeed > unlike(element); // same as before > link2(element, i); // reinsert, but use i as a hint (which will be > correct) OK, I know now where you're getting at. You are assumming that a change in the name key won't affect other indices. In general, this is not true: keys are not orthogonal, the simplest example is two indices having the same key. More interesting examples include indices with composite keys or, in general, any function that depends on the whole element rather than a single data member. OK so far? So, you just cannot feed an index with the new key and expect the other indices to remain unaltered. You *must* provide the indices with the final modified object. From this it easily follows that you need two copies: one from the original element to the modified one (which you must supply separately from the original) and other to do the final commit. If you look at the implementation of modify_ (the internal backbone of modify) you'll see that each index is given its turn to rearrange the element, not only the one from which you called modify. This is the reason behind the existence of different update and modify memfuns: there's a tradeoff between copying penalty and reversible semantics. Got it? Allow me to snip the rest of the discussion. If you're not convinced or I haven't explained myself please tell me so. [...] > > > [...] > > > Some of the lines are > 80 columns (e.g.: the copyright notice). > > > > Is this strictly required? If so I'll go thru the code and make the > > changes. If not, I'd rather leave it like that. > > I don't think it's strictly required, but a lot of people complain > about long lines. Reluctantly added to my todo list (I'm lazy.) > > > <off topic> It'd be nice if Boost.Config provided a (possibly > > automatically generated) reference table showing which > > compilers do have a specific defect macro.</off topic> > > That would be great, but as with many things, complaints are > usually satisfied by the complainer. ;) > Oh, I'm too young for commitment :) [...] > > Well, I stated previously that I'll do what people agree on. I don't > > know if the final decision should be made by Pavel as the review > > manager. IMHO, qualified identifiers will be so long anyway that > > having an additional ::container:: won't hurt much. > > It won't hurt, but if it won't help, why should it be there? We > can add > gratuitous namespace levels all day long, but that doesn't mean > we should. Others (not talking about me) think differently. > > > [...] > > The main problem with "Set" slipping into the name of the > > container is that, for instance, the following > > > > indexed_set<int,index_list<sequenced<> > > > > > > does not have anything to do with sets (it resembles a std::list of > > constant ints.) For this reason I like Multicontainer better (or > > something along this line.) > > Perhaps, but "multicontainer" sounds *too* generic. I would expect > something with that name to support any number of back-ends, like > vector, deque, etc. Actually, come to think of it, that might not be > such a bad idea. However, it wouldn't really fit the implementation > of the library, because the container is a node-based one, and > vector wouldn't play as nicely as the others. But if you could not > only created computed indices, but also *virtual indices*, then you > could create an associative vector! However, this might exceed > the scope of the library. By a virtual index, I mean that the vector > itself would remain sorted, and you would have an index that > performs a binary search without actually storing any additional > node information. That sounds like a big mess, though. I don't think I'll go down that route. As you point out, the container delivers for node based structures. > > The reason I think that "Set" is ok is that the STL "Set" is only > vaguely related to mathematical sets. The only property of > essence that is related to mathematical sets is the uniqueness > property, and even that is violated by the multiset. The vagarities > of computational performance necessitate that the STL notion > of Set be stricter than the mathematical notion for it to be usable. > In the same way, I think that IndexedSet need not strictly be even > an STL Set for similar reasons. It supports the "essential > properties" of uniqueness and intrinsic ordering, and adds > additional concepts which cater to computational practicalities. > It's not *merely* a container, but a special kind of container. It's > not truly a generic container, so I think it would benefit from a > more specific name. It's primarily associative, and that's the > essence of the STL Set, which is why I think your container > ultimately *is* a set, even though a degenerate configuration > may not be. Then again, not even the general feel of a std::set has to be met. Imagine a bunch of sequenced indices (like a lot of std::list without duplicate storage): this is not just a degenerate case (it might be useful) and it is definitely not a set. I agree "Multi" is probably too generic, and clashes with, for instace, multi_array. What about CompositeContainer for the lib (and composite_container for the class)? it matches the name of the concept it satisfies, it *is* some sort of container and it's certainly composite. Admittedly a bimap could be also a considered a composite container, but composite_container is *the* composite container, if you know what I mean. Please allow me to answer the rest of your post in a separate message so as to keep its size bounded. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Bo Persson wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> skrev i meddelandet >news:BAY7-F123eo6WutfjDM00010dd8@hotmail.com... > > Klaus Nowikow wrote: > > >Reece Dunn wrote: > > >[snip] > > > > A trick I use when handling HRESULT error codes is to have a > > > > class like this > > > > (adapted for int error type): > > > > > > > > class errorcheck > > > > { > > >[snip] > > > > public: > > > > inline errorcheck( int ec ): error( ec ) > > > > { > > > > if( ec < 0 ) throw( *this ); > > > > } > > > > > >Careful. Throwing an exception from a constructor > > >means that the object won't be constructed (i. e., does not exist). > > >So you are throwing a non-existing object here. > > > > > >Or am I wrong? > > > > If I've got the standard correct, the object will be partially >constructed > > up to the point where the exception is thrown. Thus, if this throws an > > exception, the error member will be set. > >No, when the constructor fails any partial construction will be undone by >calling the destructors for those subobjects. So the errorcheck object will be in a half-constructed state. That is, the int will be constructed, but the errorcheck object isn't, therefore the int's destructor will be called, but errorcheck's deconstructor will not. The solution would therefore be to throw an intermediate object, like the Trules from the C++ Templates book by David Vandervoorde and Nico Josuttis. This would then get around the throwing in a constructor problem. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

small but handy (to me) data buffer class
by Matthew Hurd 30 Mar '04

30 Mar '04

I'm a simple fellow and get confused about who is responsible for deleting a raw buffer, is it me, the library, should it be free or delete? Maybe I get a pointer the buffer and I must free it. May I get the pointer to the buffer and I should do nothing... When I create the buffer and send it to the library, the lib will delete, so I shouldn't but should I malloc or new the thing? Any way, to kill annoying mozzie with a hammer I wrote a little policy buffer, perhaps others might find this useful and it might make its way into a utility section somewhere in boost. I also had a goal of the potential for binary compatibility with a struct buffer { size t size; char * data; } as per WSABUF on win32, and many other standardish buffers, which limited the choices a little. hpp attached. Test that passes on vc7.1 below: Seem trivial enough but there are plenty of colours on the bike shed that might be wrong ;-) Comments? If it is desirable I can write a one page doc and put it in the queue for a mini-review. Matt Hurd. __________________________________________ void data_test() { net::data_standard b(6, "Hello"); CPPUNIT_ASSERT_EQUAL( b[0], 'H'); CPPUNIT_ASSERT_EQUAL( b[1], 'e'); CPPUNIT_ASSERT_EQUAL( b[2], 'l'); CPPUNIT_ASSERT_EQUAL( b[3], 'l'); CPPUNIT_ASSERT_EQUAL( b[4], 'o'); CPPUNIT_ASSERT_EQUAL( *b.begin(), 'H'); net::data_standard::iterator i = b.begin(); CPPUNIT_ASSERT_EQUAL( *i, 'H'); CPPUNIT_ASSERT_EQUAL( *(i+4), 'o'); ++i; CPPUNIT_ASSERT_EQUAL( *i, 'e'); i++; CPPUNIT_ASSERT_EQUAL( *i, 'l'); --i; CPPUNIT_ASSERT_EQUAL( *i, 'e'); i = b.end(); i = i - 3; CPPUNIT_ASSERT_EQUAL( *i, 'l'); i = b.begin(); *i = 'h'; CPPUNIT_ASSERT_EQUAL( b[0], 'h'); b[1] = 'u'; CPPUNIT_ASSERT_EQUAL( std::string( b ), std::string("hullo") ); std::string c = b; CPPUNIT_ASSERT_EQUAL( c, std::string("hullo") ); net::data_standard::const_iterator ci = b.begin(); CPPUNIT_ASSERT_EQUAL( *ci, 'h'); ci = b.end(); ci = ci - 3; CPPUNIT_ASSERT_EQUAL( *ci, 'l'); CPPUNIT_ASSERT( b.end() - b.begin() == 6); // malloc / free example where one side creates and the other destroys net::data<4096, net::create_malloc, net::kill_nothing > source; std::string bye = "Goodbye"; source.overwrite(bye.length() + 1 , bye.c_str()); net::data<4096, net::create_refer, net::kill_free > dest( source.size() , source.begin() ); std::string bye_bye = dest; CPPUNIT_ASSERT_EQUAL(bye, bye_bye); } ______________ 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> constructed for char with 6 incoming | d:\finray\simple_server\data.hpp:158 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Empty data<4096> constructed for char | d:\finray\simple_server\data.hpp:145 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> constructed for char with 8 incoming | d:\finray\simple_server\data.hpp:158 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> for char has the fat lady singing | d:\finray\simple_server\data.hpp:165 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> for char has the fat lady singing | d:\finray\simple_server\data.hpp:165 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> for char has the fat lady singing | d:\finray\simple_server\data.hpp:165 OK (1)

2 6

Re: [boost] anonymous namespaces and Intel C++ 8
by Matthias Troyer 30 Mar '04

30 Mar '04

On Dec 14, 2003, at 9:55 PM, Matthias Troyer wrote: > In trying to get our boost-based codes to compile with Intel C++ > version 8 I realized one important restriction of that compiler with > anonymous namespaces (used in boost for the placeholder symbols _1, > _2,... ). With Intel C++ version 8 these anonymous namespace symbols > give multiple definition errors at link time if they occur in two > different object files with the same name (even if one of these object > files is part of a static library (.a file). The only solution I could > find is to rename all my source files that clashed with file names > inside libraries. Does anybody know a better workaround? I want to report that this bug has been fixed in the latest release. Matthias

1 0

Re: Patches for Octonion/quaternion libs
by Hubert Holin 30 Mar '04

30 Mar '04

Somewhere in the E.U., le 29/03/2004 Bonjour I am happy to see you managed to keep this library alive while I was in limbo. My current plans for it (and its siblings) is to transition from MWCWPro to XCode (gcc), to add valarray support to the various special functions (it was on the way, and is locally partially implemented), and further on to replace the quaternion/octonion input operators by something sane, probably based upon Spirit. Were there any requests formulated that I missed? Merci Hubert Holin

2 3

[Boost-bugs] [ boost-Bugs-926039 ] examples/kruskal-example.cpp shadows variables
by SourceForge.net 30 Mar '04

30 Mar '04

Bugs item #926039, was opened at 2004-03-30 06:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=926039&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: examples/kruskal-example.cpp shadows variables Initial Comment: $g++ -Wshadow -Wall kruskal-example.cpp -lbgl-viz generates a lot of shadow warnings, making it impossible to use kruskal-example related code in a program that is supposed to be shadow-free. $g++ --version g++ (GCC) 3.3.3 (Debian 20040321) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=926039&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: IndexedSet Review
by JOAQUIN LOPEZ MU?Z 30 Mar '04

30 Mar '04

Hi Dave, 2nd part of your post. ----- Mensaje original ----- De: "David B. Held" <dheld(a)codelogicconsulting.com> Fecha: Lunes, Marzo 29, 2004 9:57 pm Asunto: [boost] Re: IndexedSet Review [...] > > As for the Composite Sorted Associative Container concept, we > > have the same problem. Technically, the requirements imposed > > to current or future index types by indexed_set are much weaker > > than being some sort of associative container. I cannot even state > > global complexity bounds (please check the reference, page > > "Index reference", section "Complexity signature"). > > Ok, so if the concept is not a refinement of Associative Container, > then create a new concept! > > > I agree with you a concept section would be highly desirable, but > > here I definitely need some help. What you request is not trivial. > > Then let's take a first stab at it. What you have is similar to an > Associative Container, but is fundamentally different. The way in > which it is different is that there is more than one way to access > the data. And, as you say, it is like multiple containers in one. > So > I think the most fundamental concept here is Composite Container. > [...] Agreed. > Let's rip off SGI for a minute: > > Description > > A Composite Container is a variable-sized Container that > supports retrieval of elements (values) based on one or more > keys. It supports insertion and removal of elements, but differs > from an Associative Container in that the complexity of the > operations depends on the type of key indices used. Not agreed. A Composite Container is more primitive than that. Keys properly belong to the indices (some indices are even not key-based.) I would try first to forge the Index concept. Then a Composite Container is more or less trivially defined as a "composition" (wants definition) of indices. We could call an Associative Composite Container to a Composite Container whose indices model Associative Index (wants def). A bimap is a model Assoc Comp Container, as well as some instantiations of indexed_set. The part of index retrieval (the get<> stuff) I don't see any hope of being conceptualized, as bimap, for instance, could perfectly lack such interface in favor of something simpler for the data structure at hand. Probably, a Composite Container is *not* any kind of Container (its indices are, though): imagine an indexed_set that does not inherit the functionality of its first index. [...] > Now, here we have a tricky issue. By default, IndexedSet *is* > default constructible, but we can't say that Composite Container > should be, because IndexedSet might *not* be default c'tible if > one of the key types are not. The STL solved this by simply > implicitly requiring key comparators to be default c'tible, but > perhaps this requirement is not justified. Anyway, let's continue: Oh, I hadn't thought of this before. Really std::sets implicitly require that their key objetcs are Default Constructible. Seems a defect to me. [snipped rest of stuff] Well, all these sections really belong (IMHO) to the Index concept. > > Models > > * indexed_set (of course) > * bimap (if anyone makes it ;) > > That's a start anyway, and if you fill in as much of that as you can, > I think others will be able to help you fill in the rest. It also > mighthelp if you define other concepts first, like Ordered Unique > Index,etc. I know it's a lot of work, but I think it's worthwhile > (especiallyfor people wanting to extend the library, i.e.: by > defining custom > index types). Well, I'll try to come up with something, but it'll take long. If this is a requirement for acceptance, it certainly will affect to the availability time. > > > [...] > > My Latin (I speak Spanish) heritage makes me favor "indices" > > to "indexes" (and "minuscule" to "miniscule", etc.) The Google > > metric could be biased by the fact that "indexes" is not only the > > plural of "index" but also the 3rd singular formal of the Present > > tense of the verb "index". > > Good call! That was some sloppy reasoning on my part. ;) To be honest, there's bias on the other side to: "indices" is a valid French and Spanish word. Cheers, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Problem: no matching function for call to `parse(const char*, RE_Parser&, const boost::spirit::space_parser&)
by Stephen Torri 30 Mar '04

30 Mar '04

I am having problems with compiling a simple parsing example that I created. I have read over half of the spirit guide and took one of the examples a guide for creating my program. Here is the full error message that I hinted above. What is wrong with my code? I am using boot-1.31.0 with gcc-3.3.2 (gentoo). g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"cs507_EC\" -DVERSION=\"0.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../../src -O2 -c -o RE_Parser.o `test -f RE_Parser.cpp || echo './'`RE_Parser.cpp RE_Parser.cpp: In function `int main()': RE_Parser.cpp:18: error: no matching function for call to `parse(const char*, RE_Parser&, const boost::spirit::space_parser&)' make[2]: *** [RE_Parser.o] Error 1 The code is: -------------------- Parser -------------------- #ifndef RE_PARSER_H_ #define RE_PARSER_H_ #include <string> #include "FileException.hpp" #include <boost/spirit.hpp> #include <iostream> using namespace std; using namespace boost::spirit; //namespace re_parser { class RE_Parser; struct RE_Grammar : public grammar<RE_Grammar> { template <typename ScannerT> struct definition { definition (RE_Grammar const& self) { r_rule = *r_rule[&RE_Parser::process_Kleene] | (r_rule >> s_rule)[&RE_Parser::process_Concat] | (r_rule >> ch_p('+') >> s_rule)[&RE_Parser::process_Or] | s_rule[&RE_Parser::process_Char]; s_rule = ch_p('a') | ch_p ('b') | ch_p ('c') | ch_p ('^') | ch_p ('0'); } rule<ScannerT> r_rule, s_rule; rule<ScannerT> const& start() const { return r_rule;} }; }; class RE_Parser { public: void process_Kleene (char const*, char const*){ cout << "Kleene star" << endl;}; void process_Concat (char const*, char const*){ cout << "Concatenate" << endl; }; void process_Or (char const*, char const*, char* const*){ cout << "Or" << endl;}; void process_Char (char const*){ cout << "Char" << endl;}; }; //} /* namespace re_parser */ #endif /* RE_PARSER_H_ */ ---------- Main ---------- #include "Parser.hpp" #include <string> #include <iostream> #include <fstream> using namespace re_parser; int main () { RE_Parser reg_rdr; string input_str; ifstream reg_file; reg_file.open("reg_expr.txt"); while (getline(reg_file,input_str)) { parse_info<> info = parse(input_str.c_str(), reg_rdr, space_p); if (info.full) { cout << "Parsing succeeded." << endl; } else { cout << "Parsing failed. Stopped at: " << info.stop << endl; } } } Stephen -- Stephen Torri GPG Key: http://www.cs.wustl.edu/~storri/storri.asc

2 1

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Vladimir Prus wrote: >John Torjo wrote: > >>> I really wish there were exception-throwing versions -- since that > >>> code is > >>> boring and still contains a couple of error-handling problems. > >>> However, most > >>> of the functions above are acutally from POSIX, not from standard C, > >>> so I'm > >>> not sure how much wrapped C functions would help me. > > Unless I'm mistaken, you're talking something similar to Andrei > > Alexandrescu's ENFORCE: > > http://www.cuj.com/documents/s=8250/cujcexp2106alexandr/ >Yes, you're right. However, there's one additional wish -- I'd like an >appraoch different macroses for different functions. E.g. for POSIX calls I >only encounter -1 returns and NULL returns for error reporting. So I'd like > int tty = check(open(check(ctermid(0)), O_RDRW); >to work. I guess this could be done by providing two overloads for the >'Wrong' function...., but not, the 'Enforcer' template only works for >specific type of return value :-( My errorcheck class (see other posts) has an error policy where you can change the fail test. The default is to test errorcode < 0. A current weakness is that it does not return the value passed to it on assignment, so you cannot use exactly like the above example. I have been updating it to support errno handling, but this (at present) requires something like: boost::errorcheck< ... > check; FILE * fp = ::fopen( 0, "r" ); check( fp != 0 ); // assert-like syntax ::fclose( fp ); If you are interested, I'll work on supporting constructs like your example above. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Index_set observations
by Tom Brinkman 30 Mar '04

30 Mar '04

Comments: Again, congratulations on this library. I see it, combined with the serialization library , as having the potential to eliminate the need for relational databases in c++ applications. Granted, if the development staff consists of DBAs and Java developers they would not agree to such a thing. However, if you have an application that consists of just c++ code, you could make the argument that relational databases are no longer needed. That would be a great thing, as relational datbases and sql are not c++ friendly. I spent many years writing c++ applications that were simply wrappers over relational datbases designed by DBAs. I've always thought that there had to be a better way. It would appear that you have done just that with this library. Questions: 1) When you add a record to an indexed_set, and it violates the index definition in some way, could you throw an exception, instead of simply replacing the original record? 2) Is there support for mult-key unique indicies. I read in the documenation that you can have more than one unique indice in the definition, but they are unique individually. Question: Can you combine two or more of those unique indice to create a multi-key unique indice. __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

8 7

IndexedSet Review
by David B. Held 30 Mar '04

30 Mar '04

*** What is your evaluation of the design? Overall, the design seems sound. I didn't look at every aspect of the design in my review, but the usage seems straightforward, and as the end-goal, I think it passes. It's too bad that you have to specify the type of the member when using member<>, but I don't see a way to infer it without having measurable runtime overhead. The range() member is very clever and is a good use case for Boost.Lambda, IMO. It seems to me that modify() need not have the destructive policy that it does. It appears that modify() erases the node from the index, then reinserts it into the appropriate place. However, it seems to me that modify() could first look to see if the modified node already exists, save the iterator to the correct insertion point, and then only unlink the node if the modification would be succesful. So the strategy would be like this: 1) Change the modifier function object to require a value() member that gives the new value to be used. 2) Instead of calling mod() right away, call something like lower_bound(), using mod.value(). Save the iterator if there isn't already an element there that conflicts. 3) Perform the erase as usual, and then do mod(), link2(), etc. Wow, Boost.Lambda looks like a home run, were it not for the fact that directly assigning to members through the set interface is a serious violation of encapsulation. ;) The safe mode and invariant checking are also nice features. Perhaps they could be a guideline or recommended feature for Boost libraries. One thing that I think should be added (though not affecting my vote) is ranked indexes. So just as an index might be unique or non-unique, it can be ranked or not ranked. Ranking gives an index an O(log n) ordinal search. That is, you can search for the ith item according to a certain index in O(log n) time, given an ordered index (obviously, the sequenced indexes would have an O(n) search time). This does change the structure of the nodes, and necessarily makes them bigger for ranked indexes. So it is not a trivial change. However, I am sure that it is doable and would add value to the library. *** What is your evaluation of the implementation? The implementation seems fairly clean, modulo the regular portability hacks. The coding style is tighter than I prefer (w.r.t whitespace) but doesn't affect my opinion of the code itself. It seems that some care has been taken to consider performance issues without necessarily providing the fastest implementation possible. While the use of MPL, Lambda, and Tuples makes the implementation a little fat, this is the kind of compile-time cost that I think is justified by the run-time and code expressivity benefits. Some of the lines are > 80 columns (e.g.: the copyright notice). I don't like the C-style comments, but I don't expect to be modifying the source, so it's not really an issue. I think that BOOST_NO_MEMBER_TEMPLATES should be deprecated. I don't think there's a single supported compiler in the Boost compiler configs that defines this any more. I think checking against BOOST_MSVC6_MEMBER_TEMPLATES is sufficient, but it would be nice to not even have to check against that. I do believe the parts that come from other code need to retain the original copyright. The parts that were inspired by, but not directly derived from, another implementation probably don't need a copyright notice, but should probably give a mention in the copyright, at the least as a matter of professional courtesy. *** What is your evaluation of the documentation? The documentation is very good, except that it could use some very minor editing (which does not affect the clarity or understandability of the documentation). Here is a somewhat minor nitpick. In the tutorial, the index_list is specified as so: (type of index)<[(tag)[,(key extractor)[,(comparison predicate)]]]> (type of index)<[(key extractor)[,(comparison predicate)]]> I would change it to thus: (unique | non_unique)<[(tag)[,(key extractor)[,(comparison predicate)]]]> (unique | non_unique)<[(key extractor)[,(comparison predicate)]]> It would be nice to be able to read through the documentation like a manual. Thus, next links on each page would be appropriate. On the performance page, you state that the tests were performed on a system with 260 KB "RAM memory", running W2K. I'm absolutely certain that is not correct. ;) "256 MB RAM" sounds a lot more likely. Something that I think should be added to the documentation is a concept page that lists the main concepts in IndexedSet and a concept interface a la the SGI STL reference (www.sgi.com/tech/stl) *** What is your evaluation of the potential usefulness of the library? I think the library is very useful and fills an important gap in the STL. I think it would be "complete" if it were to add ranked index support. Then it would be a total replacement of containers like VB's Collection. In particular, I think the key functors alone make it useful, let alone multiple indexes and the like. *** Did you try to use the library? With what compiler? Did you have any problems? I did try very briefly. However, I got blocked by BJam, and didn't take the time to d/l the latest Boost to fix it (assuming it does). I will try to get BJam working later, and if I succeed before the review is over, I will at least run the tests and create a few small test programs myself. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read all the documentation except for the reference section, and I spent some time looking over random parts of the code. *** Are you knowledgeable about the problem domain? Yes. I've had need for similar containers and have hand-rolled some solutions. The scope of IndexedSet is impressive without being too feature-bloated. *** Do you think the library should be accepted as a Boost library? Yes, most definitely. *** Naming issues: Here's my take on names, but should not be construed as affecting my vote for inclusion... Namespace: I think too many namespace levels are not helpful. A separate 'container' namespace seems a bit superfluous to me. There is no danger in name clashes within Boost between container libraries and other kinds of libraries that I can see, and I don't see that it provides a significant documentation benefit. I think additional namespace depth is most appropriate for collections of algorithms, where a proliferation of names is more likely to lead to name collisions. Library name: I don't think IndexedSet is so bad, but an alternative that I like is CompositeSet. Then there could be a Composite Sorted Associative Container concept which would support the notion of containers with multiple keys. Then CompositeSet would be a model of Composite Sorted Associative Container. A synonym for Sorted Associative Container could be Simple Sorted Associative Container or Trivial Sorted Associative Container. Indexes: According to the American Heritage Dictionary, Fourth Edition, as channeled by www.dictionary.com, "indexes" is preferred to "indices". Another spelling metric I like to use is Google. According to Google, "indexes" returns 5.8 million hits, while "indices" returns 5.5 million hits. So that's only a 5% difference, but it's statistically significant. ;) I personally think the preferred spelling should be used throughout the documentation, but that's more of a nitpick than a criticism. Anyway, I prefer "ordered index" to "regular index". As far as index types go, I prefer "ordered_unique" to "set_like", due to consistency. I think Ordered Index should be a concept for this library. Key extraction: Leave it in the library. nth_index_type: I don't like the word "nth", personally. I suggest either of the following naming schemes: nth_index_type -> ordinal_index index_type -> named_index | tagged_index nth_index_type -> index_byval | index_bynum index_type -> index_byname | index_bytag Generalize appropriately to the iterator types. update(): Actually, I do prefer "replace()" over "update()", because it does more accurately reflect the operation. As far as header organization goes, I would think of it this way: What are the major features and concepts of the library, and how will they be used separately or together? Organize the headers in a way that allows users to include feature sets as modules. If you have to, create dummy headers that just include sets of headers that are logically dependent so that users can activate a certain feature by including that header. Also, consider the cost of each header. It is worth the extra effort to isolate expensive headers than cheap ones. Other than that, I don't have any particular suggestions. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.581 / Virus Database: 368 - Release Date: 2/10/2004

5 6

Re: [boost] Index_set observations
by JOAQUIN LOPEZ MU?Z 29 Mar '04

29 Mar '04

----- Mensaje original ----- De: Shannon Stewman <stew(a)uchicago.edu> Fecha: Lunes, Marzo 29, 2004 10:33 pm Asunto: Re: [boost] Index_set observations > On Mon, Mar 29, 2004 at 08:14:09AM +0200, Joaqu?n M? L?pez Mu?oz > wrote: > > If the insertion violates some constraint, then it does > > not take place. insert operations return a > > pair<iterator,bool>: the bool indicates whether insertion > > succeeded or not. > > Forgive me if this has already been asked, but why don't you > return a > boost::optional<> object? > It has not been asked before. The only reason is that this is how STL containers (like std::set) do it. But this raises an interesting possibility. Maybe optional<T> can be augmented with a ctor accepting an std::pair<T,bool>. I'll post this in a separate thread. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

depreciated iterator warnings with gcc
by Chris Garrett 29 Mar '04

29 Mar '04

Hi, I have a simple collection template that uses boost::shared_ptr and std::list. I have used this with Borland Builder 5/6 for sometime now with no problems. I am moving some code that uses the template to GCC(3.2.3) and have found that this is giving me some depreciation warnings. A snip of my template(coll.h): template <class T> class Collection { private: list < shared_ptr<T> > items; list < shared_ptr<T> >::iterator iter; ... }; And the errors: coll.h:106: warning: `typename std::list<boost::shared_ptr<T>, std::allocator<boost::shared_ptr<T> > >::iterator' is implicitly a typename coll.h:106: warning: implicit typename is deprecated, please see the documentation for details coll.h:107: warning: `typename std::list<boost::shared_ptr<T>, std::allocator<boost::shared_ptr<T> > >::iterator' is implicitly a typename coll.h:107: warning: implicit typename is deprecated, please see the documentation for details Is there a different method that I need to use for GCC? Thanks, Chris

2 2

Boost.Thread and BoostBook
by Michael Glassford 29 Mar '04

29 Mar '04

The Boost.Thread documentation in the thread_dev branch in CVS appears to have been partially converted to BoostBook format. I've been hoping to build it to take a look and see what state it's in currently, then update pieces as I work on them. As a preliminary step, I've been trying to follow the instructions at http://www.boost.org/doc/html/boostbook.getting.started.html for building the Boost documentation that has already been converted to BoostBook but am getting errors. As I'm not very fluent yet with either bjam or BoostBook, I'd appreciate some help. FYI: I'm trying to use it on WinXP Pro without CygWin. I've already downloaded libxml, libxslt, and iconv libraries and made sure all of the pre-built utilities are on the system path. I've downloaded source for bjam and built it just today. The problem is that when I run "bjam --v2" I get the output at the end of this message and nothing builds. Any suggestions? Mike C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/tools\boostbook.jam:321: in construct warning: rulename $(base-target).depends expands to empty string C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:955: in object(boostbook-target-class)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:521: in generate-really C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:494: in object(main-target)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:179: in object(project-target)(a)9.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2\build-system.jam:160: in load C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel\modules.jam:259: in import C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel/bootstrap.jam:120: in boost-build C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\boost-build.jam:12: in module scope C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/tools\boostbook.jam:325: in construct warning: rulename $(target).set-path expands to empty string C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:955: in object(boostbook-target-class)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:521: in generate-really C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:494: in object(main-target)(a)1.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:179: in object(project-target)(a)9.generate C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2\build-system.jam:160: in load C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel\modules.jam:259: in import C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel/bootstrap.jam:120: in boost-build C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\boost-build.jam:12: in module scope C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:1060: in check-for-unused-sources from module object(boostbook-target-class)@1 warning: Unused source { src/boost.XML } in main target ./doc C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:957: in object(boostbook-target-class)(a)1.generate from module object(boostbook-target-class)@1 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:521: in generate-really from module object(main-target)@1 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:494: in object(main-target)(a)1.generate from module object(main-target)@1 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2/build\targets.jam:179: in object(project-target)(a)9.generate from module object(project-target)@9 C:/VSSNZ/Libraries/Boost/boost_cvs/boost_ssh/tools/build/v2\build-system.jam:160: in load from module build-system C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel\modules.jam:259: in import from module modules C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\tools\build\v2/kernel/bootstrap.jam:120: in boost-build from module C:\VSSNZ\Libraries\Boost\boost_cvs\boost_ssh\boost-build.jam:12: in module scope from module BoostBook warning: no DocBook XSL directory specified. If you have the DocBook XSL stylesheets installed, please set DOCBOOK_XSL_DIR to the stylesheet directory on either the command line (via -sDOCBOOK_XSL_DIR=...) or in a Boost.Jam configuration file. The DocBook XSL stylesheets are available here: http://docbook.sourceforge.net/ Stylesheets will be downloaded on-the-fly (very slow!) BoostBook warning: no DocBook DTD directory specified. If you have the DocBook DTD installed, please set DOCBOOK_DTD_DIR to the DTD directory on either the command line (via -sDOCBOOK_DTD_DIR=...) or in a Boost.Jam configuration file. The DocBook DTD is available here: http://www.oasis-open.org/docbook/xml/4.2/index.shtml The DTD will be downloaded on-the-fly (very slow!) ...found 3 targets...

2 6

c++ help for a boost synch lib
by Hurd, Matthew 29 Mar '04

29 Mar '04

Trying to find the neatest way to do this: template <class U > class c { template< class S = U> void f(Param p) { S::other lock(a); } U::something a; }; That is, I'm trying to work around not have function/method template defaults. Trying to find the least messy solution for a boost::synch library that can use alternative locking strategies, e.g. none, for a particular mutex, e.g. shareable. This is about the simplest I think I can come up with: template <class U > class c { void f(Param p) { f<U>(p); } template< S > void f(Param p) { S::other lock(a); } U::something a; }; and I could use the boost pp lib to get it to something like template <class U > class c { HACKEROOSKI ( U, void, f, Param, p) { S::other lock(a); } U::something a; }; but it is something almost every method I write will need so I end up with ugly macro code everywhere. Inner class with a default template and static fn's with a reference being passed in from the out doesn't seem to buy me much in the prettiness stakes. Any ideas on how best to approximate a default type for a template method? Is there a standard trick for this? Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [boost] Standard C Library and C++ / BOOST
by Reece Dunn 29 Mar '04

29 Mar '04

Vladimir Prus wrote: >Eljay Love-Jensen wrote: > > > Take the Standard C Library. > > Create a new namespace, "boost::xtd::" for instance. > > For every function in the Standard C Library, create an analog in the > > "boost::xtd::" namespace. > > The analog function would have the same functional behavior as the >StdCLib > > function, with the notable difference that any errors will generate an > > exception. > >Personally, I find this to be a good idea. Whenever I had to write code >like: > > int controlling_tty = open(ctermid(0), O_RDWR); > if (controlling_tty == -1) > perror("open"); > > int result = tcsetpgrp(controlling_tty, parent_group); > if (result == -1) > perror("tcsetpgrp"); > >I really wish there were exception-throwing versions -- since that code is >boring and still contains a couple of error-handling problems. However, >most >of the functions above are acutally from POSIX, not from standard C, so I'm >not sure how much wrapped C functions would help me. A trick I use when handling HRESULT error codes is to have a class like this (adapted for int error type): class errorcheck { private: int error; public: inline operator int() { return( error ); } public: inline errorcheck & operator=( int ec ) { error = ec; if( ec < 0 ) throw( *this ); return( *this ); } inline errorcheck & operator=( const errorecheck & ec ) { error = ec.error; return( *this ); } public: inline errorcheck( int ec ): error( ec ) { if( ec < 0 ) throw( *this ); } inline errorcheck( const errorcheck & ec ): error( ec.error ) { } }; try { errorcheck ec; ec = open(ctermid(0), O_RDWR); ec = tcsetpgrp(controlling_tty, parent_group); } catch( errocheck error ) { // ... } Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 3

[Boost-bugs] [ boost-Bugs-925163 ] Compiling Boost with Python without Unicode
by SourceForge.net 29 Mar '04

29 Mar '04

Bugs item #925163, was opened at 2004-03-29 17:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=925163&group_i… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Gray (codeazure) Assigned to: David Abrahams (david_abrahams) Summary: Compiling Boost with Python without Unicode Initial Comment: If compiling Boost 1.31.0 against Python 2.2.3 where Python has been compiled to not include Unicode support, Boost fails to compile. The problem is caused by a function within libs/python/source/converter/builtin_converters.cpp The function encode_string_unaryfunc() needs to be preceded by #ifndef BOOST_NO_STD_WSTRING, which is currently below the function. It is also necessary to add #define BOOST_NO_STD_WSTRING to libs/config/user.hpp to compile Boost without Unicode support. I am using Python on an embedded system where Unicode is not required and support for these libraries requires considerable memory. To build Python without Unicode support, do this: ./configure --disable-unicode ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=925163&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[program_options] nasty bug!
by Neal D. Becker 29 Mar '04

29 Mar '04

There is a bug in program_options. Now I remember, this is why I stopped using it before. It can't accept negative numbers as command line arguments! #include <boost/program_options.hpp> #include <iostream> #include <cxxabi.h> // demangle using namespace std; namespace po = boost::program_options; int main (int argc, char** argv) { double angle; std::set_terminate(__gnu_cxx::__verbose_terminate_handler); po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("angle,a", po::value (&angle)) ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("help")) { cout << desc << "\n"; return 1; } cout << "angle: " << angle << '\n'; } ./Test1 -a -0.2 terminate called after throwing a `boost::program_options::invalid_command_line_syntax' what(): required parameter is missing in '-a' Aborted

2 1

Re: [boost] Indexed Set needs a name?
by JOAQUIN LOPEZ MU?Z 29 Mar '04

29 Mar '04

Hi Tom ----- Mensaje original ----- De: Tom Brinkman <reportbase(a)yahoo.com> Fecha: Domingo, Marzo 28, 2004 11:11 pm Asunto: [boost] Indexed Set needs a name? > I think that you should call the library "Nautilus". > This name is arbitrary and sufficiently different than > any other library name on boost or stl. You are > expecting too much if you want the name of the library > to represent the complete functionality of the > library. If you named the library Nautilus, you could > then name the indexed set, just a set. Everyone nows > what a "set" is. Adding "indexed" to everthing does > not help me understand what the library does. > Well, I hope we don't have to resort to an arbitrary name. IMHO those should be reserved for larger libraries, indexed_set after all is nothing but a container full-o-gadgets. Anyway, you're right that trying to find the perfect descriptive name is probably impossible, but at least some indication on what the library is about is useful (if "index" and "container" somehow appear around, you'll know the library is not about genetic algorithms, for instance.) The review will finish in a couple of days. By the last day I'll try to propose something reasonable which, if not loved by everybody, is at least a sufficiently good compromise. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

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

29 Mar '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 6:05 pm Asunto: Re: [boost] Formal Review: Indexed Set > On Sun, 28 Mar 2004 13:56:02 +0200, JOAQUIN LOPEZ MU?Z wrote > [...] > > > 2) bidirectional_map [...] > > an example of use which I think will be common enough. > > IMHO a much more user-friendly bidirectional map could be > > developed based on indexed_set, > > Agreed -- what more would you add to the example? * the original bimap had a feature we could call "smart interface". Suppose the from and to types are different, then for instance bimap.find(from_key) bimap.find(to_key) are different and can be called without using get<>() to first select the appropriate index. If is_same<from_type,to_type>, this facility is not provided (ambiguities would arise) and the good old get<>() is the only alternative. * the example is strictly 1-1. 1-N, N-1 and N-N can be useful too, the instantiation syntax should make it ease to get all the variants. > > >but we are talking probably of a separate library. > > I don't see why. It would be a specifically targeted > multi-index container built on the flexible core. To me, > your library is now a family of collection types. Adding > targeted easy to use collections in the library makes perfect > sense. > Ummm... Sort of prefab ready-to-eat instantiations of the main container? Well, the idea looks interesting. If only you have patience for the next cycle of development. I'd like to gain some feedback from real users of the library, to see what they demand. By the end of the cycle maybe some common uses can be crystallized in specific-purpose containers to be add to the prefab gallery. Comments? [...] > > > 4) Should the SGI/HP copyrights be included in the source > files > > > which are > > > based off the stl_tree.h implementation? [...] > In reading the license in the docs, I don't think there is a > problem with > compatibility, but I believe it would be safer to also include > this notation > in the affected source -- even though the licenses sort of implies > it isn't > necessary. > <usual disclaimer> > I am not a lawyer. The above is not legal advice. > </usual disclaimer> Maybe someone else reads this and can shed some more light. > > > 5) Naming > > > [...] > boost::container::multi_index works for the namespace. But to be > clear, I'm > expecting you are going to rename the entire library to Multi-Indexed > Containers, right? I didn't think of a general alternative name for the library. Boost.MultiIndex? Boost.Multicontainer? Boost.Container.MultiIndex (in sync with the namespace)? Suggestions here most welcome. > Also, are you suggesting that I'm going to see > BOOST_ROOT/libs/container/multi_index and > BOOST_ROOT/boost/container/multi_index? This is what was just > done with the > string algorithms library (BOOST_ROOT/libs/algorithm/string/). > Yep, that's the idea. > While this structure makes perfect sense to me, it creates an > inconsistencywith existing container libraries like array and > multi_array which are not > under the .../container subtree. Personally, I'd like to see array, > multi-array, and dynamic_bitset get moved under a .../container > tree -- but it > is alot of work. > Seems to me the general perception is that sooner or later libs will be have to be migrate to the appropriate umbrella namespace; newcomers should do it right away. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

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

28 Mar '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 9:25 pm Asunto: Re: [boost] Formal Review: Indexed Set > On Sun, 28 Mar 2004 20:09:24 +0200, JOAQUIN LOPEZ MU?Z wrote > > > > > 2) bidirectional_map > > I have no problem with waiting. There's no question that on > my current project there are 5 or 6 places I could have used > bi-map. So at the moment it is the one I'd like to see. Thanx for your patience. I hope in the meantime (some months) you can get by with the bimap from the example. > > > > > > 5) Naming [about boost::container::multi_index namespace] > > Seems to me the general perception is that sooner or > > later libs will be have to be migrate to the appropriate > > umbrella namespace; newcomers should do it right away. > > Well, I'm actually not very concerned about the namespace -- it's > the > directory structure that is a major hassle to fix: CVS, doc > pointers, etc. > Its possible the other authors of containers won't want to > refactor the > directory structure. So I think we want to make sure they are > willing to do > this at some point before we send you down this path. > At this point, whatever decision involves a manageable amount of work. So I'll stick with what people like most. Further changes would be much more painful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

28 Mar '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 9:25 pm Asunto: Re: [boost] Formal Review: Indexed Set > On Sun, 28 Mar 2004 20:09:24 +0200, JOAQUIN LOPEZ MU?Z wrote > > > > > 2) bidirectional_map > > I have no problem with waiting. There's no question that on > my current project there are 5 or 6 places I could have used > bi-map. So at the moment it is the one I'd like to see. Thanx for your patience. I guess in the meantime (some months) you can get by with the bimap from examples. > > > > > > 5) Naming [about boost::container::multi_index namespace] > > Seems to me the general perception is that sooner or > > later libs will be have to be migrate to the appropriate > > umbrella namespace; newcomers should do it right away. > > Well, I'm actually not very concerned about the namespace -- it's > the > directory structure that is a major hassle to fix: CVS, doc > pointers, etc. > Its possible the other authors of containers won't want to > refactor the > directory structure. So I think we want to make sure they are > willing to do > this at some point before we send you down this path. > At this point, whatever decision involves a manageable amount of work. So I'll stick with what people like most. Further changes would be much more painful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Indexed Set needs a name?
by Tom Brinkman 28 Mar '04

28 Mar '04

I think that you should call the library "Nautilus". This name is arbitrary and sufficiently different than any other library name on boost or stl. You are expecting too much if you want the name of the library to represent the complete functionality of the library. If you named the library Nautilus, you could then name the indexed set, just a set. Everyone nows what a "set" is. Adding "indexed" to everthing does not help me understand what the library does. boost::nautilus::set boost::nautilus::list boost::nautilus::index boost::nautilus::identity Filenames boost/nautilus/set.hpp boost/nautilus/list.hpp boost/nautilus/tag.hpp boost/nautilus/index.hpp boost/nautilus/identity.hpp boost/nautilus/member.hpp boost/nautilus/mem_fun.hpp Tom Brinkman __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

1 0

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

Gennaro Prota wrote: >On Sun, 28 Mar 2004 12:55:10 +0200, "Pavel Vozenilek" ><pavel_vozenilek(a)hotmail.com> wrote: > >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > >> So is it possible to prevent derivation? If not, then at least make it > >> harder to do so (and put a warning in the docs)? > >Yes. > >Legal way: > >http://www.research.att.com/~bs/bs_faq2.html#no-derivation >And where is derivation prevented? ;) That only gives an error when >you try instantiating the derived class. (Not only you may still >derive, but of course you can access and use any static members). There aren't any static members to errorcheck, so this is fine. If you try to do something like: class foobar: public boost::errorcheck<> { // ... }; you will not get any errors until you do something like: foobar foo; which generates an error message like: VC7.1 -- test.cpp(11) : error C2248: 'boost::detail::cannot_derive_errorcheck<Storage,MsgStorage>::__ctor' : cannot access private member declared in class 'boost::detail::cannot_derive_errorcheck<Storage,MsgStorage>' with [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] and [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] and [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] d:\devel\ADL++\include\boost\errorcheck.hpp(102) : see declaration of 'boost::detail::cannot_derive_errorcheck<Storage,MsgStorage>::__ctor' with [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] and [ Storage=boost::policy::error_storage<>, MsgStorage=boost::policy::no_errormsg_storage ] VC6 -- test.cpp(70) : error C2248: 'cannot_derive_errorcheck<class boost::policy::error_storage<int>,class boost::policy::no_errormsg_storage>::cannot_derive_errorcheck<class boost::policy::error_storage<int>,class boost::policy::no_errormsg_storage>' : cannot access private member declared in class 'boost::detail::cannot_derive_errorcheck<class boost::policy::error_storage<int>,class boost::policy::no_errormsg_storage>' Borland C++5.5 -- Error E2247 test.cpp 11: 'boost::detail::cannot_derive_errorcheck<boost::policy::error_storage<int>,boost::policy::no_errormsg_storage>::cannot_derive_errorcheck()' is not accessible in function foobar::foobar() Therefore, the error message is intuitive: cannot_derive_errorcheck! Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

1 0

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

28 Mar '04

----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Domingo, Marzo 28, 2004 5:47 pm Asunto: [boost] Re: Re: Formal Review: Indexed Set > >"JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> wrote: > > >IMHO nth_iterator_type and familiy are user-level > >facilities (similar vg to Boost.Tuple get<>) and accepting > >mpl integral constants instead of raw constants does > >not make much sense here. Please somebody correct me > >if I'm wrong. > > One positive thing that could result from this would be the > possibility of > specializing the class to determine the type of the index, such as > insteadof > > nth_index_type<1>::type > > to use > > index_type<mpl::int_<1> >::type //rather clumzy, but doesn't > clash with > index_type<tag>::type > > If you then create some typedefs (possibly with the preprocessor), > somethinglike: > > typedef mpl::int_<1> _1; > ... > typedef mpl::int_<10> _10; > > This might look like: > > index_type<_1>::type; > I more or less get your approach, but still don't see what would gain us wrt the current scheme. And those typedefs will probably we disliked by many here at the mailing list. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[timer] throwing constructor?
by Gennaro Prota 28 Mar '04

28 Mar '04

The documentation for boost::timer says: "The constructors may throw std::bad_alloc." I don't see how they could. There are two of them; one is the compiler generated copy constructor and the other one is: timer() { _start_time = std::clock(); } Maybe the intent was to write it as: start_time = std::clock(); if (_start_time == (std::clock_t)(-1)) throw ...; ? But why the exception would be bad_alloc? PS: I haven't checked whether progress_timer and progress display have the same problem. PS2: I know that it is (the intent for it to be) allowed in class scope but shouldn't we refrain from using identifiers with a leading underscore? Genny.

1 0

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

28 Mar '04

Hello Jeff, thanks for reviewing the indexed_set! ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 28, 2004 5:21 am Asunto: [boost] Formal Review: Indexed Set > Let me start by saying thanks to Joaquín for the contribution of > this library. You are welcome. The experience has been a lot of fun to me. [...] > > * Do you think the library should be accepted as a Boost library? > Yes. great :) thanx! > > ********* > Now for some questions / comments: > > 1) Dead code in index_node.hpp? > > I don't think the ':' is legal below -- I assume this is dead code? > > template<typename Super> struct > index_node_trampoline:index_node_impl{}; > template<typename Super> > struct index_node:Super,index_node_trampoline<Super> > ... > This is not dead code. index_node_treampoline:index_node_impl is short for index_node_treampoline:public index_node_impl. My coding style is admiteddly a little too compact. > 2) bidirectional_map > > My first interest in this library started when it was just a bi- > directionalmap. Now it has become something much broader and more > powerful. Curiously, > the bi-directional map part seems to have taken a back seat -- > being pushed > into the examples as an 'exercise for the reader'. > > I think that this is unfortunate. I like to see bidirectional_map > as an > official part of the library. A few reasons for this: > > a) bidirectional_map will be documented up front as a part of > the library. > b) For me it is my current primary use of this library -- even > though it is > now so flexible I'll have to rethink how I use containers in designs. > c) Complex code is pushed on the user. For example, the code > below is from > examples/bimap.cpp > > template<typename FromType,typename ToType> > struct bidirectional_map > { > typedef std::pair<FromType,ToType> value_type; > > #if defined(BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS) ||\ > defined(BOOST_MSVC)&&(BOOST_MSVC<1300) ||\ > > defined(BOOST_INTEL_CXX_VERSION)&&defined(_MSC_VER)&&(BOOST_INTEL_CXX_VERSION<=700) > > .... > > It is obvious from this that there are some portability issues. > Putting this > sort of detail on library users is too mcch to expect from users > in my opinion. > > But it is only a suggestion since it took me all of 5 minutes to > pull out the > core of the example to a header file. I don't think the bidirectional map I provide in the examples section is good enough for officialization (for one, it lacks operator[]). I only wrote it as an example of use which I think will be common enough. IMHO a much more user-friendly bidirectional map could be developed based on indexed_set, but we are talking probably of a separate library. Also, when I first introduced bimap to Boost a year ago, people expressed interest in an extensible approach, which bimap's rigid interface certainly did not provide. As for the macro stuff, you probably shouldn't be concerned if the compiler you work with is reasonably conformant. > > 3) Serialization support > In future directions you say "Once Robert Ramey's serialization > library gets > accepted into Boost..." > > I'd love to see Joaquín at least attempt this soon -- it would > serve as an > excellent review of serialization which is upcoming shortly :-) Good idea, if time permits I'll engage into the review and try to sketch some serialization support for indexed_set. > > 4) Should the SGI/HP copyrights be included in the source files > which are > based off the stl_tree.h implementation? I don't know. The original pieces of code (with lots of changes) are scattered across some five headers or so. Basically it is the rb-tree algorithms that I have retained. Maybe some of the licensing wizards here at the list can offer advice on this issue. > > 5) Naming > > For the namespace/library name I suggest > boost::multiindex_containers. > > Rationale: > -- The library provides several stl-like container types (set, > list, map) -- > hence the plural 'containers'. > -- The containers all have multiple indexes -- hence multiindex. > Maybe boost::container::multi_index would please more people: it is as descriptive as your proposal, but (1) it is into boost::container and (2) avoids the abhorred "ii". Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

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

28 Mar '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 28, 2004 7:41 am Asunto: [boost] Re: Formal Review: Indexed Set > JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> writes: > > > Hi Jeff > > > > ----- Mensaje original ----- > > De: Jeff Garland <jeff(a)crystalclearsoftware.com> > > Fecha: Sábado, Marzo 27, 2004 4:55 pm > > Asunto: Re: [boost] Formal Review: Indexed Set > > > > > >> // why doesn't this work? > >> //typedef nth_iterator_type<date_to_string_bimap,2>::type > to_map_itr;> > > It is > > > > typedef nth_iterator_type<date_to_string_bimap,1>::type to_map_itr; > > > > Index numbering is 0-based. I think this is the > > only problem in the program. If you have further > > problems please tell me so. > > Not having looked at the proposal at all, I still think I should raise > the usual concerns about "metafunctions" not accepting type > parameters, which don't play nice with MPL and lambda expressions. > IMHO nth_iterator_type and familiy are user-level facilities (similar vg to Boost.Tuple get<>) and accepting mpl integral constants instead of raw constants does not make much sense here. Please somebody correct me if I'm wrong. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

David Abrahams wrote: >"Klaus Nowikow" <nowikow(a)decomsys.com> writes: >You're wrong. *this is copied before it is thrown. Still, the idiom >above seems a bit suspicious, unless you somehow prevent derivation >from errorcheck. So is it possible to prevent derivation? If not, then at least make it harder to do so (and put a warning in the docs)? Also, would a non-derivable class be a good addition to C++0x? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 3

RE: [boost] Re: Re: Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

Pavel Vozenilek wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote > > So is it possible to prevent derivation? If not, then at least make it > > harder to do so (and put a warning in the docs)? >Yes. >Legal way: >http://www.research.att.com/~bs/bs_faq2.html#no-derivation Cool! I have adapted the example to the errorcheck class, so it will report a clean error message. The code has been tested on borland 5.5 and vc-6, vc-7 and vc-7.1 and should work on other compilers. If there is interest, where in the boost-sandbox would be best to put it? My gut feeling is boost/errorcheck.hpp, but if anyone has any better suggestions... Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

Re: Formal Review: Indexed Set
by Arkadiy Vertleyb 28 Mar '04

28 Mar '04

Hi Joaquin, Sorry for joining this discussion so late, but here are my comments: - What is your evaluation of the design? - What is your evaluation of the implementation? The code looks clean. One minor question: the index class template's equal_range method forwards to lower/upper_bound. Is it really the best you can achieve here or is it just a temporary shortcut? - What is your evaluation of the documentation? I read the "tutorial" part. I believe the documentation is excelent -- does a great job of explaining things, and provides excelent examples to just be copy-pasted into the code for one to get started. - What is your evaluation of the potential usefulness of the library? At least once in my previous experience I had to maintain multiple synchronized collections. This project would have greatly benefitted from a library like the indexed set. I also think that the "compatible predicate" feature, so unfortunately missing from the std::set, is very useful. We are currently using the library to provide a set-based implementation for our RTL tables. This is not posted yet, but we hope to post it soon. We plan to eventially make the Indexed set-based table implementation default for our tables. - Did you try to use the library? With what compiler? Did you have any problems? Yes, with VC7.1. I did not have any problems related to the Indexed set. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the "tutorial" part of the documentation. Then I wrote Indexed set-based RTL table implementation, and made it default for RTL tables. After this I (eventially) successfully compiled and ran RTL tests, which, by that time all internally utilized the indexed set. I had to solve a few issues that showed up, but turned out to be our own issues (thanks for helping us to discover them). - Are you knowledgeable about the problem domain? I use STL collections a lot but never attempted to implement any non-trivial collection (I don't know if this is qualifies as domain knowledge). - Do you think the library should be accepted as a Boost library? Yes, definitely. Arkadiy

1 0

What should be called? [was: BOOST_CHECK_EQUAL fails...]
by Stefan Slapeta 28 Mar '04

28 Mar '04

Sorry for the repost, but there was no answer to this (http://tinyurl.com/3yba8) and I'm still not sure if it is a compiler or a boost defect. Which f should be called here? void f(const char*) { std::cout << "function called!" << std::endl; } template <typename T> void f(const T&) { std::cout << "function template called!" << std::endl; } int main() { char buf[10] = { 0 }; f(buf); } In my opinion, it should be the function template (which whould also mean that EDG works correctly and VC 7.1 not) as "f(char[10])" is no exact match for the function. However, this would also mean that there is a defect in boost.test (see link above). br, Stefan *********************************** Stefan Slapeta Wien/Vienna, Austria http://www.slapeta.com

2 2

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

28 Mar '04

Hi Tom, thank you for taking the effort to review indexed_set. ----- Mensaje original ----- De: Tom Brinkman <reportbase(a)yahoo.com> Fecha: Domingo, Marzo 28, 2004 7:46 am Asunto: [boost] Formal Review: Indexed Set > * What is your evaluation of the design? > * What is your evaluation of the implementation? > > This is a very creative and impressive library. It > might become as useful > as the boost::lambda, boost::spirit and > boost::function libraries are for me. > > This library has many features that would be useful > generally to many enterprise > applications. > > * What is your evaluation of the documentation? > > Again, excellant. Great work. > > * What is your evaluation of the potential usefulness > of the library? > > Being able to sort sequences of elements by more than > one sorting criteria is useful > to me. I also am intrigued by the lookup operations > and updating functionality, > mentioned in the help file, although I did not test > these. > > * Did you try to use the library? > > I compiled the samples successfully with gcc. I > re-worked the basic sample to get > a feel for some of the functionality. > > * How much effort did you put into your evaluation? > > Compiled samples and read help files. I created a > small test application. > > * Are you knowledgeable about the problem domain? > > Yes. > > * Do you think the library should be accepted as a > Boost library? > > Yes. > Thank you! If you feel in the mood, you might want to contribute your opinions about naming issues (I'll try to compose a unified naming scheme pleasing as many people as possible) The points under discussion are listed at http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Formal Review: Indexed Set
by Tom Brinkman 28 Mar '04

28 Mar '04

* What is your evaluation of the design? * What is your evaluation of the implementation? This is a very creative and impressive library. It might become as useful as the boost::lambda, boost::spirit and boost::function libraries are for me. This library has many features that would be useful generally to many enterprise applications. * What is your evaluation of the documentation? Again, excellant. Great work. * What is your evaluation of the potential usefulness of the library? Being able to sort sequences of elements by more than one sorting criteria is useful to me. I also am intrigued by the lookup operations and updating functionality, mentioned in the help file, although I did not test these. * Did you try to use the library? I compiled the samples successfully with gcc. I re-worked the basic sample to get a feel for some of the functionality. * How much effort did you put into your evaluation? Compiled samples and read help files. I created a small test application. * Are you knowledgeable about the problem domain? Yes. * Do you think the library should be accepted as a Boost library? Yes. Tom Brinkman __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

1 0

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

28 Mar '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Sábado, Marzo 27, 2004 4:55 pm Asunto: Re: [boost] Formal Review: Indexed Set > // why doesn't this work? > //typedef nth_iterator_type<date_to_string_bimap,2>::type to_map_itr; It is typedef nth_iterator_type<date_to_string_bimap,1>::type to_map_itr; Index numbering is 0-based. I think this is the only problem in the program. If you have further problems please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

RE: [boost] Re: Boost.Thread and BoostBook
by Reece Dunn 28 Mar '04

28 Mar '04

Michael Glassford wrote: >Douglas Gregor wrote: >Well, that gets me a little farther, but now xsltproc.exe crashes. The >output is attached to the end of the message. >I noticed it was defaulting to gcc, which I don't have installed, so I also >added "using msvc ;" to user-config.jam. It warns me that it found two >versions, 6 and 7.1, and that it will use 7.1, but still crashes. If I >instead add "using msvc : : c:/msvs6/vc98/bin ;" to force it to use MSVC6 >(because version 7.1 unfortunately isn't my main compiler, though we're >thankfully finally moving that way), I get the same result. I think it uses the gcc toolset regardless as a target to put the XIncluded document file in so it will work within bjam/BBv2 (I could have this wrong, as I am not a Boost.Build expert). >Any ideas about this, now? Have you checked the catalog.xml file to see if the namespace aliases are pointing to the correct locations? Does it work when you don't set the XSL/DTD environment variables, but download from the internet? (This will be slow, but it may show if the error is with the program settings or the XSL/DTD settings). Are you building from the Windows or cygwin/Linux shell? If you are using cygwin/Linux, you could try something like: using boostbook : /cygdrive/d/devel/libraries/docbook/xsl/ : /cygdrive/d/devel/libraries/docbook/dtd/ ; Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Formal Review: Indexed Set
by Jeff Garland 28 Mar '04

28 Mar '04

Let me start by saying thanks to Joaquín for the contribution of this library. The amount of effort here is staggering. I believe this will be a very handy addition to boost. * What is your evaluation of the potential usefulness of the library? Quite useful -- library provides solution to frequently requiring design problem with stl collections. It will effectively replace lots of poorer hand-coded solutions. * What is your evaluation of the documentation? Good. Quite extensive. I didn't have time to read it all. I also ran checklink on docs -- no broken links. * Did you try to use the library? With what compiler? Did you have any problems? Yes. Compiled examples and test with gcc 3.3.1 on Mandrake 9.2 against Boost 1.31. All tests passed. I also successfully wrote some code that uses library. Only problem was mine. I was having a 'Pascal' moment -- starting my index at 1 instead of zero ;-) * How much effort did you put into your evaluation? ~5 hours spent. Read docs, compiled examples, wrote programs. * Are you knowledgeable about the problem domain? Sure, if using standard collections counts ;-) * What is your evaluation of the design? Overall the design appears to be quite solid and complete. * What is your evaluation of the implementation? Cursory glance thru implementation. Overall the source seems well organized and conforms with boost standards. Of course, like many boost libraries reading the code in this library is a challenge, even though it is well written. * Do you think the library should be accepted as a Boost library? Yes. ********* Now for some questions / comments: 1) Dead code in index_node.hpp? I don't think the ':' is legal below -- I assume this is dead code? template<typename Super> struct index_node_trampoline:index_node_impl{}; template<typename Super> struct index_node:Super,index_node_trampoline<Super> ... 2) bidirectional_map My first interest in this library started when it was just a bi-directional map. Now it has become something much broader and more powerful. Curiously, the bi-directional map part seems to have taken a back seat -- being pushed into the examples as an 'exercise for the reader'. I think that this is unfortunate. I like to see bidirectional_map as an official part of the library. A few reasons for this: a) bidirectional_map will be documented up front as a part of the library. b) For me it is my current primary use of this library -- even though it is now so flexible I'll have to rethink how I use containers in designs. c) Complex code is pushed on the user. For example, the code below is from examples/bimap.cpp template<typename FromType,typename ToType> struct bidirectional_map { typedef std::pair<FromType,ToType> value_type; #if defined(BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS) ||\ defined(BOOST_MSVC)&&(BOOST_MSVC<1300) ||\ defined(BOOST_INTEL_CXX_VERSION)&&defined(_MSC_VER)&&(BOOST_INTEL_CXX_VERSION<=700) .... It is obvious from this that there are some portability issues. Putting this sort of detail on library users is too mcch to expect from users in my opinion. But it is only a suggestion since it took me all of 5 minutes to pull out the core of the example to a header file. 3) Serialization support In future directions you say "Once Robert Ramey's serialization library gets accepted into Boost..." I'd love to see Joaquín at least attempt this soon -- it would serve as an excellent review of serialization which is upcoming shortly :-) 4) Should the SGI/HP copyrights be included in the source files which are based off the stl_tree.h implementation? 5) Naming For the namespace/library name I suggest boost::multiindex_containers. Rationale: -- The library provides several stl-like container types (set, list, map) -- hence the plural 'containers'. -- The containers all have multiple indexes -- hence multiindex. I don't have an opinion on the other naming issues. Jeff

1 0

RE: [boost] Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

Klaus Nowikow wrote: >Reece Dunn wrote: >[snip] > > A trick I use when handling HRESULT error codes is to have a > > class like this > > (adapted for int error type): > > > > class errorcheck > > { >[snip] > > public: > > inline errorcheck( int ec ): error( ec ) > > { > > if( ec < 0 ) throw( *this ); > > } > >Careful. Throwing an exception from a constructor >means that the object won't be constructed (i. e., does not exist). >So you are throwing a non-existing object here. > >Or am I wrong? If I've got the standard correct, the object will be partially constructed up to the point where the exception is thrown. Thus, if this throws an exception, the error member will be set. If you had: struct test { errorcheck ec; std::string msg; test(): ec( -1 ), msg( "hello" ) { } }; an exception will be generated before the msg string is set and thus test would be invalid. However, I use it like: class myfile { ... myfile( const char * fn ) { errorcheck ec = open( fn, ... ); } ~myfile() { close( ... ); } }; where because the file is not opened if an exception is thrown above, it will not call the destructor to close a non-opened file. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

Is there any mirrors of boost?
by 胡香冬 28 Mar '04

28 Mar '04

I cannot access www.boost.org, :(

2 1

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

27 Mar '04

Hi Joerg ----- Mensaje original ----- De: jhr.walter(a)t-online.de (Joerg Walter) Fecha: Sábado, Marzo 27, 2004 6:44 pm Asunto: Re: [boost] Re: Formal Review: Indexed Set > > OTOH it might be surprising to search for the components of one > library in > different namespaces. Yes, probably indexed_set should live in boost::container::whatever with the rest of associated components, and additionally, be lifted to boost or boost::container. > > Two more remarks: > > 1. Documentation > > My linux browser (konqueror) has difficulties to correctly display the > indexed_set documentation. HTML tidy shows a couple of problems. Please send them to me privately and I'll try to fix them. > > 2. Performance test > > Compiling the performance tests with ICC 8.0 uncovered a problem in > indexed_set.hpp: > > 67,69c67,69 > < template <typename,typename,typename,typename> friend class > detail::index_base; > < template <typename,typename> friend class > detail::header_holder; > < template <typename,typename> friend class > detail::converter; > --- > > template <typename,typename,typename> friend class > detail::index_base;> template <typename,typename> > friend class > detail::header_holder; > > template <typename,typename> friend class > detail::converter; There's an extra typename in the friend declaration for index_base, right? I wonder how this splipped through unnoticed for so long. I'll fix it, thanx for the tip. > Test results for GCC 3.3.2 > > 1 regular index > 10^3 elmts: 141.24% > 10^4 elmts: 147.67% > 10^5 elmts: 152.57% > space gain: 100.00% > 1 sequenced index > 10^3 elmts: 154.99% > 10^4 elmts: 157.43% > 10^5 elmts: 153.71% > space gain: 100.00% > 2 regular indices > 10^3 elmts: 108.23% > 10^4 elmts: 124.78% > 10^5 elmts: 121.79% > space gain: 90.00% > 1 regular index + 1 sequenced index > 10^3 elmts: 123.96% > 10^4 elmts: 137.12% > 10^5 elmts: 145.98% > space gain: 87.50% > 3 regular indices > 10^3 elmts: 100.11% > 10^4 elmts: 119.70% > 10^5 elmts: 129.12% > space gain: 86.67% > 2 regular indices + 1 sequenced index > 10^3 elmts: 99.25% > 10^4 elmts: 113.62% > 10^5 elmts: 116.37% > space gain: 84.62% > > Test results for ICC 8.0 > > 1 regular index > 10^3 elmts: 105.45% > 10^4 elmts: 106.74% > 10^5 elmts: 105.98% > space gain: 100.00% > 1 sequenced index > 10^3 elmts: 112.29% > 10^4 elmts: 112.20% > 10^5 elmts: 111.43% > space gain: 100.00% > 2 regular indices > 10^3 elmts: 63.17% > 10^4 elmts: 67.35% > 10^5 elmts: 71.65% > space gain: 90.00% > 1 regular index + 1 sequenced index > 10^3 elmts: 65.19% > 10^4 elmts: 69.00% > 10^5 elmts: 72.62% > space gain: 87.50% > 3 regular indices > 10^3 elmts: 49.76% > 10^4 elmts: 57.97% > 10^5 elmts: 60.94% > space gain: 86.67% > 2 regular indices + 1 sequenced index > 10^3 elmts: 49.07% > 10^4 elmts: 52.71% > 10^5 elmts: 51.55% > space gain: 84.62% > > I don't have an explanation for the difference. > How have you compiled the performance test in GCC? Maybe you forgot to turn on optimization flag -O3. The library has a jamfile that builds all the test, examples and the eprformance test, if you use this the performance program should compile in release mode. I except performance results to be roughly the same as with GCC 3.3.1, which I measured in my performance section. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] errorcheck (was Standard C Library and C++ / BOOST)
by Reece Dunn 27 Mar '04

27 Mar '04

Thorsten Ottosen wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote in message > > > A trick I use when handling HRESULT error codes is to have a class like >this > > (adapted for int error type): > >Maybe you should start on such a small helper library and submit it? I have attached what I have so far. It is a policy-based approach that allows you to specify the error type/check mechanism and a message holder. It also fixes the throw on constructor problem mentioned by others. e.g. try { boost::errorcheck<> ec = 7; ec = -1; std::cout << "Hello\n"; } catch( boost::errorcheck<> ec ) { std::cout << "error: check failed" << '\n'; } output ==> error: check failed If you want to note the function called from, like in Volodya's examples, you can use: typedef boost::errorcheck< boost::policy::error_storage<>, boost::policy::errormsg_storage > msgerrorcheck; try { msgerrorcheck em; em( "open" ) = -1; em( "write" ) = 3; } catch( msgerrorcheck em ) { std::cout << "error: " << em.get_msg() << '\n'; } output ==> error: open This is a slightly different syntax, but gives what is intended. NOTE: I have not yet provided an errno class, but it should not be difficult to do. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Bug in Date_Time library + Patch
by Frank Wolf 27 Mar '04

27 Mar '04

Hi all! While adding some additional functionality to the Date_Time library I've found a minor bug in it: According to the documentation the contructor of the "ptime" type also accepts a special value but this overloaded constructor is missing in the library code. I've made this trivial fix and attached a patch file... Regards, Frank

2 2

RE: [boost] Re: Formal Review: Indexed Set
by Powell, Gary 27 Mar '04

27 Mar '04

>Hi Gary, thanks for reviewing the library! You are welcome. It's always a pleasure to see another cool library. >Have you looked at the performance section? No, will do soon. >Umm... Sequenced indices are modelled after std::list, which >contains both erase and remove operations, with different >semantics (remove meaning erasing *all* elements with a given >value.) yeah but vector, does a "move"... blech.. its in the details section, do what you want. >If you still have time to devote to the library, please >please take a look at the review notes on naming and >header organization and cast your opinions: >http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html Namespace: I like boost::container::multi_indexed_sets But I could live without the "::container". I'm not crazy about lifting the namespace into boost. I foresee that boost is going to get cluttered so some organization early will help. "mix" hits my pun loving funny bone, hence it shouldn't be used! Besides "mix_in" has a different meaning and will confuse people. I don't have to type the name of the container very often in comparison to everything else so a clear name is worth a few extra characters. Regular indices: I like "ordered indices" as it says what they are. I hate writing documentation when readinghte code explains everything clearly. Index names: ordered_unique ordered_non_unique They say what they do. Always good for self docuementing code. "set_like" sounds so 90's teenage talk... "whatever.." Nth_index_type & family. Yeah, I'd like to see the _type dropped. If you have to have a unique name, "_t" is ok, but still sucks. Header Organization: The only reason for omitting dependant headers is if they are not "dependent." I.e. that you need the sub header for accessing the container, but the primary header is all that is needed to declare the container. Otherwise include everything that is required. (IMO) >> Sorry to hear about your cat. I had one that only made it to 3 yrs, and >that was hard to take. But cats gotta be cats. >Thanks. First time I had an animal companion in decades, >so I wasn't prepared for this sense of loss. BTW, once some time has passed, get another one. There are plenty of nice ones that need a home. Least ways there are always a heap of cats in the pound. They are never the same but each has been worth it. -Gary-

3 3

Re: [program_options] good work
by Hagen Moebius 27 Mar '04

27 Mar '04

Hi list, > Thanks for your encouragement! I, too, hope that the library will be added > to CVS soon -- the only issue that was specifically requested as needed > before inclusion is Unicode support. I've already made up my mind how to > best add it, but it might take a couple of weeks to discuss the approach > and really implement it. At this point I would like to state a question I have since some time. How is a boost library supposed to implement unicode support? There seems to be no Unicode support in the whole STL standard and not in boost either, except for the wide character support which as far as I know is limited to UCS-2 (or does it allow UCS-4?) Anyway, with linux, the most common unicode system is UTF-8. And I can seem to find any library or functionality in any way to support this (world-wide) accepted approach. Now, I wouldn't like to support the UTF-8 idea but it is impossible for a unix/linux developer to do something meaningful withou doing it some unicode way. So, what is the boost approach to undicode? Thanks and regards ... Hagen M.

2 1

Moving tss changes from thread_dev branch to HEAD
by Michael Glassford 27 Mar '04

27 Mar '04

The thread_dev branch in CVS contains a number of changes to the thread_specific_ptr / tss implementation that I would like to move to the main branch. I plan to look at it more carefully before I do so, but will anyone interested please take a look at the implementation on the thread_dev branch to see if has any problems (or if there are known problems that it doesn't fix)? It contains changes to fix a number of issues with the current implementation, including, among others: 1) thread_specific_ptr::reset() doesn't check error: http://lists.boost.org/MailArchives/boost/msg55713.php. 2) Double deletes: http://lists.boost.org/MailArchives/boost/msg50266.php, http://lists.boost.org/MailArchives/boost/msg50543.php, http://lists.boost.org/MailArchives/boost/msg30433.php, http://lists.boost.org/MailArchives/boost-users/msg05531.php. 3) Not enough tss keys/slots: http://lists.boost.org/MailArchives/boost/msg55376.php, http://lists.boost.org/MailArchives/boost/msg55712.php. 4) Ability to register custom cleanup functions. For reference, see: tss.hpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/thread/t… tss.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… threadmon.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… Mike

3 8

RE: errorcheck
by Reece Dunn 27 Mar '04

27 Mar '04

Eljay Love-Jensen wrote: >Hi Reece, > >Cool! I think I'll add that to my repertoire. Glad you like it :). >A slight tweak, and it can ignore the passed in value, and peep at errno. >I'd call that "errnocheck" (or errnoCheck ... my orthographical standard). Sure. The class I posted is an adaption of com::result that deals with Windows/COM HRESULT error handling that simplifies COM object usage. It may be possible to use a policy-based approach, something like: struct DefaultCheck { static bool IsError( int err ) { return( err < 0 ); } }; struct ErrNoCheck { static bool IsError( int err ) { return( errno < 0 ); // ??? } }; struct HRESULTCheck { static bool IsError( HRESULT hr ) { return( FAILED( hr )); } }; template< class ErrorPolicy = DefaultCheck, typename T = int > class errorcheck { public: inline errorcheck( T e ): error( e ) { if( ErrorPolicy::IsError( e )) throw( *this ); } // ... }; // example usage: errorcheck<> error; error = open( ... ); // ... errorcheck< ErrNoCheck > en; en = std::sin( -1 ); errorcheck< HRESULTCheck, HRESULT > hr; BSTR str; hr = pStyle -> get_color( &str ); or maybe to have extended information, so you could use something like: error( open( ... ), "open" ); en( ::sin( -1 ), errno ); en( ::cos( 0 )); // use errno by default Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Re: [boost] Re: Naming Issues [part of Formal Review: Indexed
by Dave Gomboc 26 Mar '04

26 Mar '04

> The standard may have made a mistake. It's fairly easy to > swallow "multixxx" but when there are more x's it gets much harder. Multigraph, multitask, multihyphenate, multimethod, etc. -- I think it's normal. Dave

3 2

Standard C Library and C++ / BOOST
by Eljay Love-Jensen 26 Mar '04

26 Mar '04

Dear BOOST folks, Here's an recipe idea for a BOOST library: Take the Standard C Library. Create a new namespace, "boost::xtd::" for instance. For every function in the Standard C Library, create an analog in the "boost::xtd::" namespace. The analog function would have the same functional behavior as the StdCLib function, with the notable difference that any errors will generate an exception. Some of my projects here at work have done something similar, with a limited subset of C. That subset being only those handful of routine that we cared about. The value of having this in the BOOST repertoire: 1. a (BOOST) standard convention that would be the same for everyone 2. maybe it'd get folded into ISO/IEC 14882 at some future point 3. Standard C Library with C++ exceptions Example 18 header files being... <boost/xtd/stdio.hpp> <boost/xtd/stdlib.hpp> <boost/xtd/stddef.hpp> <boost/xtd/stdassert.hpp> <boost/xtd/time.hpp> <boost/xtd/errno.hpp> <boost/xtd/ctype.hpp> <boost/xtd/wtype.hpp> <boost/xtd/string.hpp> <boost/xtd/wchar.hpp> <boost/xtd/locale.hpp> <boost/xtd/limits.hpp> <boost/xtd/float.hpp> <boost/xtd/setjmp.hpp> <boost/xtd/signal.hpp> <boost/xtd/math.hpp> <boost/xtd/iso646.hpp> <boost/xtd/stdarg.hpp> Opinions of this idea merits being implemented? Does it sound appropriate for a BOOST library? Sincerely, John "Eljay" Love-Jensen Adobe Systems Incorporated

3 2

[program_options] simple question
by Neal D. Becker 26 Mar '04

26 Mar '04

So far I see examples where the result of using program_options parsers is to store something into a variable map. Is it possible to directly store results into variables? For example, assume: int main (int argc, char** argv) { double value = 10.; mythical_parser (...); }; How do I use program_options to set "value"? Any examples? So far the only way I know is: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("value", po::value<int>()) ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("value")) value = vm["value"].as<int>();

5 8

boost::bind and boost::lambda::bind
by Matthew Hurd 26 Mar '04

26 Mar '04

Got tripped up again today by boost::thread's boost::function constructor not working with boost::lambda::bind but working fine with boost::bind. Silly me. Been down that track before many moons ago... It is still a tad confusing, a unification would be nice sometime, but perhaps a note in the thread and/or function documentation in the meanwhile. Regards, Matt Hurd.

2 1

Question on DLL import/export
by Vladimir Prus 26 Mar '04

26 Mar '04

Reading http://www.boost.org/more/separate_compilation.html I see suggestion that all library sources start with: #define BOOST_WHATEVER_SOURCE #include <boost/whatever.hpp> Is there any particular reason why this define should be placed in source, and not in Jamfile for the library? E.g: dll boost_program_options : ...some sources... : <define>BOOST_PROGRAM_OPTIONS_SOURCE ..... ; - Volodya

2 1

RE: [boost] Re: Formal Review: Indexed Set
by Powell, Gary 26 Mar '04

26 Mar '04

I have been reading the code, and am working through the docs. I compiled and ran the examples with gcc 3.2. All compiled and ran as advertised. I did try with gcc 2.95.3 but it fails :< I have occasionally needed a container just like this one. So I am glad to see such a nice one being offered to boost. I made an earlier comment about operator== et.al. I don't think its worth holding up this change in attempt to get all the std::containers and boost containers to conform. I did complain about this with circular buffer but I've deleted the response. If no one else complains about this, I'll write a paper for the std committee for presentation in Redmond in Oct 2004. I don't see the harm in fixing containers as they are proposed to boost though. When we first wrote the VTL library we did this with no ill effects. I have not run any timing tests, of using this container vs using two (N) maps with links or whatever with pointers to the same data. A small nit, sequenced_index::remove and sequenced_index_remove should be called "erase". Its a small nit because they live in "details". But really they do erase. I like having index_fwd.hpp I wish all the std::containers had such a file. Also you should look at Dave Abraham's and my paper on Move semantics/copy construction vs Andrei's MOJO. IMO Its worth implementing. :> BTW, I also really like the example that uses boost::lambda to help set up the conditionals! And a plug for my library in no way influences my vote.. no sir yee, I'm totally impartial here... I vote to accept unconditionally. Yours, -Gary- PS Sorry to hear about your cat. I had one that only made it to 3 yrs, and that was hard to take. But cats gotta be cats.

2 1

[program_options] post-review version
by Vladimir Prus 26 Mar '04

26 Mar '04

The first post-review version of the program_options library is now available. I believe that all important interface changes are finished and would like to ask for feedback on the current version, before I go on. Some of the interesting changes include: - better way to describe option values - support for positional options - support for environment variables The library and documentation can be obtained at http://zigzag.cs.msu.su:7813/program_options The documentation can also be browsed online at http://zigzag.cs.msu.su:7813/program_options/html And the source can also be browsed online at http://zigzag.cs.msu.su:7813/repos/trunk/program_options Since the interface has changes quite a bit, the brief list of changes is included in docs, to help with migration. See http://zigzag.cs.msu.su:7813/program_options/html/ch01s04.html All comments are very appreciated. - Volodya

7 32

min/max again. opinions? speak now.
by Eric Niebler 26 Mar '04

26 Mar '04

I was hoping I'd be able to fix this once and be done with it, but alas it is not to be. I need to change my fix. The problem has been noted here already in the thread "std_min/std_max reference return value is problematic with boost::interval." Basically, the std_min/std_max helpers cannot be made to work on old compilers that cannot detect reference returns. I have to rip out std_min and std_max. If you want to make an unqualified call to min or max, the recommended way will be as follows: using std::min; min BOOST_PREVENT_MACRO_SUBSTITUTION ( a, b ); I have 2 questions: 1) Is this the best name for the macro? Perhaps people would prefer something shorter. I'm open to suggestions. 2) Is there anyone who wants me to hold off until they finish making some big check-in to avoid merge hell? If so, please contact me privately and we'll work out a schedule. Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

Re: about license
by Alexander Terekhov 25 Mar '04

25 Mar '04

< I'll reply to the .user post here because .devel is much faster ;-) > Jonathan Arnold wrote: > > A little late to this license party, but I want to make sure I > know what it means: > > David Abrahams wrote: > > Marleny Rafferty <marleny(a)rafferty.net> writes: > > > >>Hi- > >> > >>I am considering using boost in my applications, but I have a question > >>about the boost license at http://www.boost.org/LICENSE_1_0.txt . It > >>says (edited) "Permission is hereby granted, free of charge, to ... > >>use [and] reproduce ... the Software". > >> > >>It also says that any derivative works must also have the same license > >>grant. > >> > >>If my application uses boost libraries unchanged, is it considered a > >>derivative work? > > > > Yes. Nope. It is considered a compilation (mere aggregation if you like) and only if the "distribution package" of the application includes the boost stuff (which is the case with things like templates). I presume "black box" type of usage according to boost's functional specs, of course. (no copying of protected elements[1] from boost into "your" code) http://www.digital-law-online.com/lpdi1.0/treatise27.html (see VI.D.4. Derivative Works and Compilations) > > > >>If so, does that mean that if I distribute my compiled software, I > >>must allow free of charge use and distribution? > > > > No, the license gives an explicit exemption for compiled code > > So if we use boost in our program: > > 1] If we sell it as a compiled program, we can retain our own license > > 2] If we sell it to a customer who wants the source code too, we have > to use the boost license, and thus the customer is free to give our > source code away at that point? Yes/Yes (lack of explicit distribution permission for derivative works aside for a moment). But only the portions that are truly derivative works of (in the sense of the copyright law) [and/or] original boost licensed work(s). IOW, all your non-derivative code is unconditionally[2] yours and you're free to distribute and license it on whatever terms you like (well, but you should better stick to lawful/enforceable terms, of course ;-) ). You might want to take a look at the CPL FAQ and perhaps also this: http://www.xfree86.org/pipermail/forum/2004-March/004248.html regards, alexander. [1] http://www.digital-law-online.com/lpdi1.0/treatise24.html [2] http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7651

1 0

[Boost.Format] 64 bit failure test case
by Angus Leeming 25 Mar '04

25 Mar '04

This test code aborts at run time when compiled against version 1.31 of the boost libraries using g++ 3.3.3 on a Linux/Alpha machine (64bit architecture.). It also aborts at run time when compiled against current cvs. #include <boost/format.hpp> #include <string> #include <iostream> using std::string; string bformat(string const & fmt, string const & arg1) { return (boost::format(fmt) % arg1).str(); } int main() { std::cout << bformat("Creating directory %1$s and running configure...", "/home/foo/.bar") << std::endl; return 0; } I believe that I have tracked down the cause of the failure. Adding this patch to format/feed_args.hpp $ diff -u lyx/devel/boost/boost/format/feed_args_orig.hpp lyx/devel/boost/boost/format/feed_args.hpp --- lyx/devel/boost/boost/format/feed_args_orig.hpp 2004-03-24 15:13:50.000000000 +0000 +++ lyx/devel/boost/boost/format/feed_args.hpp 2004-03-24 15:10:59.000000000 +0000 @@ -162,6 +162,14 @@ static_cast<std::streamsize>(specs.truncate_ - !!prefix_space), oss_.pcount()); + std::cout << "std::numeric_limits<std::streamsize>::max() " << std::numeric_limits<std::streamsize>::max() << '\n' + << "specs.truncate_ " << specs.truncate_ << '\n' + << "!!prefix_space " << !!prefix_space << '\n' + << "static_cast<std::streamsize>(a - b) " + << static_cast<std::streamsize>(specs.truncate_ - !!prefix_space) << '\n' + << "oss_.pcount() " << oss_.pcount() << '\n' + << "res_size " << res_size << std::endl; + mk_str(res, res_beg, res_size, w, oss_.fill(), fl, prefix_space, (specs.pad_scheme_ & format_item_t::centered) !=0 ); } leads to the following output prior to the code aborting: $ ./trial std::numeric_limits<std::streamsize>::max() 9223372036854775807 specs.truncate_ -1 !!prefix_space 0 static_cast<std::streamsize>(a - b) -1 oss_.pcount() 14 res_size -1 Aborted specs.truncate_ is being initialised incorrectly in the format_item constructor because it is an int (sizeof(4)) whilst std::streamsize has sizeof(8) on the Alpha. FWIW, I attach the gdb backtrace also. Note the 'size == -1' in #9 of this backtrace. Hoping this all makes sense, Regards, Angus (gdb) where #0 0x00000200002384a8 in kill () from /lib/libc.so.6.1 #1 0x0000020000238224 in raise () from /lib/libc.so.6.1 #2 0x0000020000239bb0 in abort () from /lib/libc.so.6.1 #3 0x00000200000ff638 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5 #4 0x00000200000ff690 in std::terminate() () from /usr/lib/libstdc++.so.5 #5 0x00000200000ff82c in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0x0000020000098d30 in std::__throw_length_error(char const*) () from /usr/lib/libstdc++.so.5 #7 0x00000200000ed348 in std::string& std::string::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*) () from /usr/lib/libstdc++.so.5 #8 0x00000200000e9a34 in std::string::append(char const*, unsigned long) () from /usr/lib/libstdc++.so.5 #9 0x0000000120008ec8 in void boost::io::detail::(anonymous namespace)::mk_str<char, std::char_traits<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, long, long, char, std::_Ios_Fmtflags, char, bool) ( res=@0x120025a58, beg=0x1200265e8 "/home/foo/.bar", size=-1, w=0, fill_char=32 ' ', f=4098, prefix_space=0 '\0', center=false) at feed_args.hpp:73 #10 0x0000000120008568 in void boost::io::detail::(anonymous namespace)::put<char, std::char_traits<char>, std::string const&>(std::string const&, boost::io::detail::format_item<char, std::char_traits<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, boost::io::basic_outsstream<char, std::char_traits<char> >&) (x=@0x11ffff950, specs=@0x120025a50, res=@0x120025a58, oss_=@0x11ffff738) at feed_args.hpp:165 #11 0x0000000120007544 in void boost::io::detail::distribute<char, std::char_traits<char>, std::string const&>(boost::basic_format<char, std::char_traits<char> >&, std::string const&) (self=@0x11ffff6e0, x=@0x11ffff950) at feed_args.hpp:241 #12 0x00000001200056c8 in boost::basic_format<char, std::char_traits<char> >& boost::io::detail::feed<char, std::char_traits<char>, std::string const&>(boost::basic_format<char, std::char_traits<char> >&, std::string const&) ( self=@0x11ffff6e0, x=@0x11ffff950) at feed_args.hpp:249 #13 0x0000000120003b0c in operator%<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0x11ffff6e0, x=@0x11ffff950) at format_class.hpp:61 #14 0x00000001200035f8 in bformat(std::string const&, std::string const&) ( fmt=@0x11ffff930, arg1=@0x11ffff950) at trial.C:11 #15 0x0000000120003748 in main () at trial.C:16

2 3

UnitTest/BOOST_CHECK_EQUALS always fails with Intel + C-strings
by Stefan Slapeta 25 Mar '04

25 Mar '04

BOOST_CHECK_EQUAL c style strings does not work on Intel if strings are passed in a buffer: char val[10]; strcpy(val, "test"); BOOST_CHECK_EQUAL("test", "test"); // ok BOOST_CHECK_EQUAL(val, "test"); // fails always The reason: void f(const char *, const char *) { } template <typename T1, typename T2> void f(const T1&, const T2&) { } int main() { char val[100]; strcpy(val, "test"); // Here is the difference to VC 7.1: // VC calls f(const char *, const char*) // Intel calls the function template f(val, "test"); } I would guess that Intel works correctly here as f(const char*, const char*) is no exact match for the arguments char[10], const char*. Any suggestions? Stefan *********************************** Stefan Slapeta Wien/Vienna, Austria http://www.slapeta.com

1 0

[program_options] good work
by Neal D. Becker 25 Mar '04

25 Mar '04

I am really excited to see program_options progress. From my limited testing so far it looks really good, and I have been looking forward to using it in my code. I hope we can add it to boost soon, because I'm reluctant to rely on unreleased boost code. The doc needs work. It was hard for me to find the doc for the function parse_environment for example. There needs to be links from the top-level html page. Also, how can I build the html docs myself from the distributed xml? It looks like I need the "boost v2" build stuff, but I don't know what that means.

2 5

[Threads] Much faster try_mutex on Windows NT
by Adal Chiriliuc 25 Mar '04

25 Mar '04

Hello. try_mutex uses a Mutex instead of a CRITICAL_SECTION because on Windows 9x and Me it's impossible to try the aquisition of a CRITICAL_SECTION. On Windows NT/2000/XP this is possible, using the function TryEnterCriticalSection. So I suggest this: choose at runtime what syncronization primitive to use based on the running OS. CRITICAL_SECTIONS are much faster and since Windows NT is gradually replacing Windows 9x systems I think it is good to use this feature. A sketch follows. ---------- mutex.cpp ----------- namespace { bool g_Init = false; bool g_UseTryCritical; TryCriticalProcType g_TryCritical; void TryCriticalInit() { g_Init = true; g_UseTryCritical = false; get windows version; if (!windows nt) return; lib = load library (kernel32.dll); g_TryCritical = get proc address (lib, TryEnterCriticalSection); g_UseTryCritical = true; } } try_mutex::try_mutex() { if (!g_Init) TryCriticalInit(); if (g_UseTryCritical) { try { m_mutex = reinterpret_cast<void*>(new CRITICAL_SECTION); } catch (...) { } } else { m_mutex = reinterpret_cast<void*>(CreateMutex(0, 0, 0)); } if (!m_mutex) throw thread_resource_error(); if (g_UseTryCritical) InitializeCriticalSection(reinterpret_cast<LPCRITICAL_SECTION>(m_mutex)); } bool try_mutex::do_trylock() { if (g_UseTryCritical) { return g_TryCritical(reinterpret_cast<LPCRITICAL_SECTION>(m_mutex)) != 0; } else { unsigned int res = 0; res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), 0); assert(res != WAIT_FAILED && res != WAIT_ABANDONED); return res == WAIT_OBJECT_0; } } ---------- mutex.cpp ----------- There is only one potential problem: if (!g_Init) TryCriticalInit(); might not be thread safe. Something like a thread safe singleton might be needed. Or maybe we could use InterlockedExchange & co. I'm not sure if timed_mutex could also benefit from this. In the docs you should explain what joining means. I worked a lot with threads in the past, but I've never heard of such a concept. I had to look through the source codes to understand what join means. Many Win32 developers will not know of concepts not covered by the Platform SDK. You do explain that conditions are some sort of events, but you use joining in sample code without explaining what it does. Regards, Adal Chiriliuc

7 13

RE: [boost] Re: [Threads] Much faster try_mutex on Windows NT
by Hanson, Iain 25 Mar '04

25 Mar '04

> Dijkstra's 1965 paper "Cooperating Sequential Processes" > explained the > problems associated with events and any other constructs that > depend on > processing speed assumptions to work correctly. That paper > was recently > reprinted in the book "The Origin of Concurrent Programming", > Per Brinch > Hansen, editor, 2002. > "Cooperating Sequential Processes" is also available here. http://www.cs.utexas.edu/users/EWD/ewd01xx/EWD123.PDF /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

[BGL] How to fix read_graphviz? with spirit?
by HIRAKI Hideaki 25 Mar '04

25 Mar '04

Hello there, I submitted a bug fix on read_graphviz() to the bug tracker (Bug ID 865882, see P.P.S. below for the summary). When thinking about possible fixes, I got some questions. Q1) May boost depend on build tools other than C++ compiler? There seemed to be a building problem due to the dependency of the parser code on some specific versions of bison. This is not a real problem because the generated C++ codes are bundled. I think the dependency should be removed, if possible. Q2) How easy is it to migrate a flex/bison code to spirit? Boost seems to have its own parser generator, spirit. Its features are uncertain for me. I just expect that it is straightforward for an expert of spirit to write a reentrant parser to be replaced with the current flex/bison parser. Q3) Why boost::subgraph isn't general subgraph but "induced" subgraph? BGL seems to have a fundamental restriction on reading graphviz files. The graph data read in read_graphviz() is stored in the boost::subgraph<> where any edge connecting vertices of a subgraph is assumed to be part of the subgraph. This is against the semantics of the graphviz format. For example, digraph g0 { edge [color=blue] subgraph g1 { edge [color=red] n1 -> n2 } n1 -> n2 } this graph has one edge in the subgraph g1 (red) and the other not in g1 (blue). But the graph read by BGL must have both edges belonging to g1. I guess that the complexity to realize this restriction may be the cause for the wrong codes in boost/graph/subgraph.hpp (see the comments at the lines 603 and 612). Anyway, a handy data structure to treat general subgraph is useful. I hope boost::subgraph will be the one. Q4) How are the graph adapters for graphs of graphviz library? Another option imagined is wrapping the graphviz library. This will introduce library dependency instead of build tool dependency. But no parser need to be developed. A data structure for general subgraph will be provided as a wrapped object. BGL seems to include wrappers for Stanford GraphBase and LEDA, C++ libraries. How are they adapted to graphviz, a C library? Regards, Hideaki Hiraki P. S. To Vladimir Prus: I'm sorry to lay this subject aside so long. I appreciate your every effort. P. P. S. Summary of the bug: The problem was that calling read_graphviz() for the second time was failed. The fix was to clear the garbage left in static variables: --- boost_1_31_0/libs/graph/src/graphviz_parser.yy Fri Aug 29 16:02:59 2003 +++ boost/libs/graph/src/graphviz_parser.yy Mon Jan 26 18:16:16 2004 @@ -259,6 +259,10 @@ graph_header: graph_type graph_name { + graphviz::vlist.clear(); + graphviz::attributes.clear(); + graphviz::subgraphs.clear(); + graphviz::nodes.clear(); std::string* name = static_cast<std::string*>($2); graphviz::previous_graph = static_cast<graphviz::Subgraph*>(g); graphviz::current_graph = static_cast<graphviz::Subgraph*>(g); This workaround was found without understanding the code. As this worked for me, I gave up digging more. A better fix may remove the uses of static variables. The item in the bug tracker has been closed but is accessible: http://sf.net/tracker/index.php?func=detail&aid=865882&group_id=7586&atid=1…

3 4

borland-5.6.4, auo_link and common-names (v1)
by Hugo Duncan 24 Mar '04

24 Mar '04

The boost/build/v1 common-names rule computes a toolset name of "bcb56" when using borland-5.6.4-tools. The boost/config/auto_link.hpp file does not discriminate between bcb5.5 and bcb5.6, using "bcb". Auto link therefore fails. I have made the following local fix to auto_link.hpp, since to me the common-names toolset name computation seems to be self-consist across toolsets. Whould it be possible to fix either auto_link.hpp or the boost build v1 common-names rule - whichever makes more sense. Thanks Hugo Index: auto_link.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/auto_link.hpp,v retrieving revision 1.9 diff -u -r1.9 auto_link.hpp --- auto_link.hpp 21 Jan 2004 11:54:55 -0000 1.9 +++ auto_link.hpp 22 Mar 2004 14:09:39 -0000 @@ -120,9 +120,14 @@ // vc71: # define BOOST_LIB_TOOLSET "vc71" -#elif defined(__BORLANDC__) +#elif defined(__BORLANDC__) && (__BORLANDC__ >= 0x560) // CBuilder 6: +# define BOOST_LIB_TOOLSET "bcb56" + +#elif defined(__BORLANDC__) + + // BCB: # define BOOST_LIB_TOOLSET "bcb" #elif defined(__ICL)

4 7

Naming Issues [part of Formal Review: Indexed Set]
by Pavel Vozenilek 24 Mar '04

24 Mar '04

This should be starting point of discussions about proper indexed_set naming. indexed_set name was picked long before the library gained much more functionality. Instead of changing name immediatelly it was decided to wait on opinion of others (any change requires quite a lot of work). Here are my suggestion of names, with rationale: 1. the data structure should be named "multi_container" and should reside (or be lifted) in boost namespace. Rationale: it is superset of std::set/multiset/list and possibly slist and deque). Therefore the "multi". The structure is important and will be probably unique - therefore the boost namespace. 2. library specific names that won't fit into boost namespace should be in "multiindex" namespace. Rationale: it will be used mainly for index related names. The name is aso reasonably short. 3. indexes should be named: set_like, multiset_like, list_like, slist_like, deque_like. Rationale: it gives idea to user what it is about (more than e.g. sequenced). 4. Since indexed_set::unique may clash with std::unique I suggest to use words "distinctive", "non_distinctive". Rationale: I found it in a dictionary as the only one word synonum to unique. English native comment welcomed. /Pavel

5 6

FC++ Review results: Real Soon Now
by Mat Marcus 24 Mar '04

24 Mar '04

Some folks have been wondering whether they missed the FC++ review results. I am still working on it. I must apologize for the delay, but please be assured that completion of the determination is at the top of my list of priorities. - Mat

1 0

[Boost-bugs] [ boost-Bugs-918568 ] signals
by SourceForge.net 24 Mar '04

24 Mar '04

Bugs item #918568, was opened at 2004-03-17 23:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918568&group_i… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Rodgers (mark_rodgers) Summary: signals Initial Comment: //to suppoet intel-win32 under inter8.0, change bellow! file:singals namespace boost { namespace BOOST_SIGNALS_NAMESPACE { class trackable; namespace detail { // Represents an object that has been bound as part of a slot, and how // to notify that object of a disconnect struct bound_object { void* obj; void* data; void (*disconnect)(void*, void*); bool operator==(const bound_object& other) const { return obj == other.obj && data == other.data; } bool operator<(const bound_object& other) const { return obj < other.obj; } //Add by ty, to support intel 80 compiler, 2004/03/18 bool operator!=(const bound_object& other) const { return !(*this==other); } bool operator>(const bound_object& other) const { return !(*this < other); } }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918568&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

RE: [boost] Re: Formal Review: Indexed Set
by Powell, Gary 24 Mar '04

24 Mar '04

>> I think there may be the problem that the various predicates used for >> the indices do not generally define comparison operators which compare >> predicates specialized on different types. >I think Gary and you are talking about different things. >As you point out, there are difficulties in using the >internal comparison objects of indices for defining >operator <. Moreover, the standard clearly dictates that >comparison between containers a and b be implemented as >lexicographical_compare(a.begin(),a.end(),b.begin(),b.end()) >leaving no option to use other comparison predicate than >operator < between element objects (see std 23.1.5) A rationale >for the decision of not using the internal comparison >predicates is given in >http://www.sgi.com/tech/stl/FAQ.html >(section "Why doesn't map's operator< use the map's comparison >function?") >So, IMHO there's little doubt that operator < between indices >of an indexed_set must use value_type::operator <, >conterintuitive as it may seem. A similar reasoning applies >to equality comparison between indices. >Now, what Gary proposes (if I understand it right) is that >we extend operator == and < so that indices on different element >types can be compared. As I see it, this can be legally done, and >it should do no harm as it merely extends the current >functionality. It'd be something along these lines: >template<...(1),...(2)> >bool operator==( > const *index class*<...(1)>& x, > const *index class*<...(2)>& y) >{ > return x.size()==y.size()&&std::equal(x.begin(),x.end(),y.begin()); >} >template<...> >bool operator<( > const *index class*<...(1)>& x, > const *index class*<...(2)>& y) >{ > return std::lexicographical_compare(x.begin(),x.end(),y.begin(),y.end()); >} >where ...(1) and ...(2) are (possibly different) sets of >template intantiation arguments for *index class*. >Is this what's being proposed? Right! Sorry I was too terse in my previous email. There is no reason why not to extend operator==() and operator<() to allow for two different container types to be compared. Either there is a comparison that will work for the two types or there is not, but it isn't the indexed set that enforces it, but rather std::equal and std::lexigraphical_compare. So the proprosal is to also extend all of the comparison operators to take the two complete sets of templated arguments. ie. Old: template<typename Value,typename IndexSpecifierList,typename Allocator> bool operator==( const indexed_set<Value,IndexSpecifierList,Allocator>& x, const indexed_set<Value,IndexSpecifierList,Allocator>& y); New: template<typename Value1,typename IndexSpecifierList1,typename Allocator1> template<typename Value2,typename IndexSpecifierList2,typename Allocator2> bool operator==( const indexed_set<Value1,IndexSpecifierList1,Allocator1>& x, const indexed_set<Value2,IndexSpecifierList2,Allocator2>& y); etc.. AFAIK there is no penalty for the library and much to be gained for the user. Yours, -Gary-

3 4

Suggested addition for BOOST_WORKAROUND
by Gennaro Prota 24 Mar '04

24 Mar '04

Hi, as pointed out when BOOST_WORKAROUND was being discussed, Borland C++ (I think, up to 0x600 excluded) just emits an optional warning for division by zero. The warning is enabled by default, but can be turned off with -w-zdi or -w-8082. So I (re)propose to add a special BOOST_WORKAROUND implementation for it: #if defined(__BORLANDC__) && (__BORLANDC__ < 0x600) // Borland needs a special version, as it just emits a warning for // division by zero (and you can even disable it with -w-zdi or // -w-8082 !!). But it supports sizeof expressions in #if-s // (NOTE: that's non-conforming) // # define BOOST_WORKAROUND(symbol, test) \ (((symbol) != 0) && (1 != sizeof(char[1 + ((symbol) test)]) )) #else # define BOOST_WORKAROUND(symbol, test) \ ((symbol != 0) && (1 % (( (symbol test) ) + 1))) ... Notes: a) it should be verified whether version 0x600 has the same problem or not; given that it uses an EDG front-end it probably won't, but who knows what they could have decided in the name of backward non-conformity :) b) I suggest to use __BORLANDC__ directly, instead of the (maybe) upcoming BOOST_BORLAND_xxx, to avoid including config.hpp for such a simple header. PS: Giovanni, I asked you in private mail a while ago. What does your 'typo revealing' patch do? -- Genny.

2 4

[program_options] post-review version -- compile problem
by Rob Lievaart 24 Mar '04

24 Mar '04

Hi, I just downloaded and compiled the version 262 of the library using Mingw (gcc 3.2.3) and I ran into a problem compiling parser.cpp: The function parse_environment contains the following lines: #if defined(_WIN32) char **environ = _environ; #endif But the mingw provided stdlib.h contains an unconditional #define environ _environ So it does not compile :-( I changed parser.cpp to #if defined(_WIN32) && !defined( __MINGW32__ ) char **environ = _environ; #endif And now it compiles and the samples run, but I have not actually tried to use enviroment variables. Also I checked the stdlib.h provided with MSVC6.5 and that contains #ifdef _POSIX_ extern char ** environ; /* pointer to environment table */ #else But I guess this would not cause a problem when _POSIX_ is defined, because the local environ would just hide the one from stdlib.h. And a small question, is the library supposed to work with 6.5 at all? I get a rather large amount of errors and warnings when I try to build it. I haven't looked into them yet, if it is not supposed to work then I won't spend any time on it. Rob Lievaart

3 3

RE: [boost] Formal Review: Indexed Set
by Powell, Gary 24 Mar '04

24 Mar '04

After a first quick review of the code, indexed set has the same problem as circular queue does with comparison operators. Only one value type comparison is possible. IMO, if two value types have a valid comparison operation, then they are comparable. Memory allocation should have no bearing on this, and the types do not have to be identical. i.e. an indexed set of shorts, { 1, 2, 3 } is equal to an indexed set of longs { 1L, 2L, 3L }. This means that less user code is written for these sort of things. More to come as I have time to spend... -Gary-

3 2

RE: [boost] FC++ examples?
by Rozental, Gennadiy 24 Mar '04

24 Mar '04

On Wed, Mar 03, 2004 at 08:03:20PM +0100, Giovanni Bajo wrote: > Are there a couple of examples showing real-life C++ problems that can be > solved with the help of FC++? > The paper > FC++: Functional Tools for OO Tasks > on the FC++ web page talks about how to use FC++ in the implementation > of common OO design patterns. The web page also points to the XR and for all these patterns we already have different (much better IMO) solutions. > > help, within a normal C++ program. The quicksort example was very cool, but it > > turns out that the generated code is too slow to be used for everything. If I > > need FP everywhere, I change language. > The quicksort example and also the tree iterator example I posted are > interesting. I posit that there are cases where shorter/easier code > may be more valuable than code that wins on raw performance, but > perhaps this is too-unpopular an idea among C++ people. Do you really beleave that quicksort could be an example that shows usefullness of lazy lists? I don't say that raw performance sould be primary goal, but an abstraction price should be commensurable to advantages. And I still do not see a single example of that. Gennadiy.

1 0

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 24 Mar '04

24 Mar '04

> out. I think the sheer difficulty of generic/template/ > meta-programming should cause us to welcome thorough examples > of working libraries, because at the least, they show us what > can and can't be done, and serve as a model full of lessons > that can be re-used in other contexts. Let's not mix apples and oranges. C++ type system present natural environment for FP techniques, and we bound to use them. While submitted library promote FP in runtime environment. And I found it difficult to justify to myself need for that without clear examples and tests. > Even just discussing > the library helps formalize idioms and practices that maybe > some people find obvious, but are not gathered together into > any definitive document. These idioms already formalized pretty good in FP dedicated literature. Gennadiy.

6 14

Interpretation of failing prg_exec_fail2 regression test
by Toon Knapen 24 Mar '04

24 Mar '04

Currently the prg_exec_fail2 regression test fails on IBM VisualAge but this depends on how you interpret it. This regression test is supposed (by its creator) to fail at runtime because of a detection of a division by zero. If the executable does not detect the division by zero, the regression test is reported to fail. AFAICT this is not a failure of the executable on IBM, this is just a property of the executable. The idea of the regression tests is to verify if there are no regressions (by definition) and they are also used to verify if the compiler and created exe react as required by the standard. Well AFAIK nowhere is required that a division by zero is detected. It's just that some processors detect it, others don't. But I don't think regression tests should not be used to test 'properties' of the compiler or executable. Because I for instance interpret a failing regression test as being an error of the compiler or exe. There is a way though to detect division by zero with VisualAge by setting a specific pragma. However this incurs a runtime penalty (for the extra error checking code) so we don't want to do this in general. So I can assure the test to run as expected but I don't want to cripple performance just for the sake of passing this regression test. I can see 2 solutions: 1) Or regression tests are not used anymore to test *properties* of the platform/compiler/exe 2) Or I include the pragma only for this regression test just for the sake of passing the test. I definitly prefer option 1 because I consider option 2 as a cheat. toon

2 1

status of FC++ review
by Dave Gomboc 24 Mar '04

24 Mar '04

> The circular_buffer library by Jan Gaspar has > been accepted into Boost. Did I miss the accept/reject for FC++? Dave

2 1

boost FSM and another idea
by jp 24 Mar '04

24 Mar '04

hey boosters i was searching for finite state machine ideas and i came across some old posts from Bryan Ross and Andreas Huber regarding a boost fsm. i love boost, even tho i havent really used it much. i intend to get to grips w/ boost::graph soon. i dont kno if there is now a boost::fsm. the above messages were in 2002! anyway, i have been using an object oriented fsm pattern for years now which uses virtual function dispatching in place of the old function pointer table thingy. i find it very robust & easy to understand. i have made a few preliminary ventures into boosting it into a generic template, and i wonder if theres still any interest in this idea. i have a tendency to see everything in computer science as either a graph or a proposition, so i find fsm's almost universally applicable... heheh another offspring of my fevered brain is a little lisp (or maybe its a scheme..?), & i wondered about adding something like this to boost. it is already amenable to templated type extensions and *i* like it. i call it terp, so maybe it could be called boost::terp. any comments? cheers. jp the a/p

12 20

[Boost-bugs] [ boost-Bugs-922097 ] Bugs in atomic_count_gcc.hpp
by SourceForge.net 23 Mar '04

23 Mar '04

Bugs item #922097, was opened at 2004-03-24 00:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=922097&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Huber (andreas_huber69) Assigned to: Nobody/Anonymous (nobody) Summary: Bugs in atomic_count_gcc.hpp Initial Comment: These have been reported before: http://lists.boost.org/MailArchives/boost/msg57537.php ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=922097&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Review Result: Circular Buffer
by Pavel Vozenilek 23 Mar '04

23 Mar '04

The circular_buffer library by Jan Gaspar has been accepted into Boost. The reviews were helpful in finding at least one issue with the library and few ones with its documentation. Thanks to all reviewers for the time and effort! Post-review version 3.7 will be released before code gets into main CVS. Main points to be addressed: - issue of copy construction versus construct/destruct has been cleared (the problem was created by me) - documentation should list exception safety for every function - documentation may add some rationale on its internal data structures and their advantage over std::deque - portability problems should be solved - adaptor with notification when oldest element gets pushed out of bufer may be added Other points that may be considered: - name of data() function - existence of push_back(void) like functions - using new iterator adaptors - difference between resize/set_capacity may be more emphasized in docs, - other fixes/improvements suggested during review. Thanks for professional quality work, Jano. /Pavel

1 0

AW: [boost] Design flaw in Date-Time Library?
by Wolf, Frank 23 Mar '04

23 Mar '04

Hi Jeff, > > 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. > > Where is this? It's in file "period.hpp" after line 35. > I believe I agree, but it is going to take awhile to evaluate > the impact. In the meantime, I recommend using is_null() to > avoid this. Or if you want to take a crack at changing the > logic on your own it is really a matter of modifying the > date_time/period.hpp file. Well I already changed period.hpp for me. That's what I did: 1. Replaced member "last_" by new one called "end_" which now stores the next point in time not belonging to the period. 2. Changed all methods, operators and constructors to use the new variable correctly. 3. Added a new constructor which accepts just a "ptime" as argument. Unfortunately I couldn't make regression tests to ensure that this change doesn't have any negative side effects. Regards, Frank ps: is_adjacent() is using method "begin()" where it could use "begin_" instead which might be more efficient. ******************************************* 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. *******************************************

1 0

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

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

[config] Patch for Intel 8.0 + Dinkum lib
by Gennaro Prota 22 Mar '04

22 Mar '04

Intel C++ for Windows never stops surprising me with its Microsoft bugtibility conundrums. When you use /Qms0 (version 8.0) it defines _MSC_VER to be 1200, as if it emulated VC++6! This tricks up the code in config/stdlib/dinkumware.hpp to define # define BOOST_NO_STD_USE_FACET # define BOOST_HAS_TWO_ARG_USE_FACET However the two-arg version of use_facet is deprecated and marked as such with __declspec(deprecated). Attached is an obvious patch to fix the problem. -- Genny. begin 644 dinkumpatch.txt M*BHJ(&1I;FMU;7=A<F4N:'!P+F]R:6<)5'5E($9E8B`@,R`Q,SHT,3HT-2`R M,#`T"BTM+2!D:6YK=6UW87)E+FAP<`E&<FD(a)36%R(#$R(#$X.C(W.C,T(#(P M,#0**BHJ*BHJ*BHJ*BHJ*BHJ"BHJ*B`R.2PS-B`J*BHJ"B`@(R`@("`@9&5F M:6YE($)/3U-47TY/7U-41%]!3$Q/0T%43U(-"B`@(R`@96YD:68-"B`@(R`@ M9&5F:6YE($)/3U-47TA!4U]005)424%,7U-41%]!3$Q/0T%43U(-"B$@(R`@ M:68@*&1E9FEN960H7TU30U]615(I("8F("A?35-#7U9%4B`\(#$S,#`I*2`F M)B`A9&5F:6YE9"A?7T)/4DQ!3D1#7U\I#0H@("`@("`@("\O(&EF('1H:7,@ M;&EB('9E<G-I;VX@:7,@<V5T('5P(&9O<B!V8S8@=&AE;B!T:&5R92!I<R!N M;R!S=&0Z.G5S95]F86-E=#H-"B`@(R`@("`@9&5F:6YE($)/3U-47TY/7U-4 M1%]54T5?1D%#150-"B`@(R`@("`@9&5F:6YE($)/3U-47TA!4U]45T]?05)' M7U5315]&04-%5`T*("`@("`@("`O+R!#(&QI8B!F=6YC=&EO;G,@87)E;B=T M(&EN(&YA;65S<&%C92!S=&0@96ET:&5R.@T*+2TM(#(Y+#,W("TM+2T*("`C M("`@("!D969I;F4@0D]/4U1?3D]?4U1$7T%,3$]#051/4@T*("`C("!E;F1I M9@T*("`C("!D969I;F4@0D]/4U1?2$%37U!!4E1)04Q?4U1$7T%,3$]#051/ M4@T*(2`C("!I9B`H9&5F:6YE9"A?35-#7U9%4BD@)B8@*%]-4T-?5D52(#P@ M,3,P,"D@)B8@0D]/4U1?24Y414Q?0UA87U9%4E-)3TX@/"`X,#`I("8F("%D M969I;F5D*%]?0D]23$%.1$-?7RD-"B`@("`@("`@+R\@:68@=&AI<R!L:6(@ M=F5R<VEO;B!I<R!S970@=7`@9F]R('9C-B!T:&5N('1H97)E(&ES(&YO('-T M9#HZ=7-E7V9A8V5T.@T**R`@("`@("`O+R`H8V%U=&EO;CH@26YT96P@."XP M(&9O<B!7:6X@=VET:"`O46US,"!D969I;F5S(%]-4T-?5D52('1O(&)E(#$R M,#`@8G5T(&ET(&ES(&YO="!60S8A*0T*("`C("`@("!D969I;F4@0D]/4U1? M3D]?4U1$7U5315]&04-%5`T*("`C("`@("!D969I;F4@0D]/4U1?2$%37U17 M3U]!4D=?55-%7T9!0T54#0H@("`@("`@("\O($,@;&EB(&9U;F-T:6]N<R!A @<F5N)W0@:6X@;F%M97-P86-E('-T9"!E:71H97(Z#0IB ` end

4 26

recommend logging library?
by Neal D. Becker 22 Mar '04

22 Mar '04

I notice boost doesn't have a logging library. I have seen several floating around. Are there any recommendations?

13 24

[fsm] Finally ...
by Andreas Huber 22 Mar '04

22 Mar '04

... has boost::fsm reached a reasonably stable state. Code, examples and documentation can be found here: http://boost-sandbox.sf.net/fsm.zip The documentation can also be browsed online: http://boost-sandbox.sf.net/libs/fsm Comments, questions, etc. are most welcome. Andreas Huber

1 0

[filesystem] relative_to
by John Torjo 22 Mar '04

22 Mar '04

Dear boosters, I noticed that currently there's no way to get the relative path of path A related to path B. What I mean is, given two **complete** paths, to get the relative path of one related to the other. To give a real example, I have an application that starts in directory initial_path(). I have several dialogs that allow the user to browse for files. My requirement is, after the user browses for a file, to internally ALWAYS store the path relative to initial_path(). Since there's no way to do this currently, I created my own function. Do you think it could be a useful addition to filesystem library? // converts the given path, making it relative to the src path // // precondition: dest & src are both complete path relative_to( const path & dest, const path & src) { // both paths should be complete assert( dest.is_complete() && src.is_complete() ); path::iterator dest_begin = dest.begin(), dest_end = dest.end(); path::iterator src_begin = src.begin(), src_end = src.end(); path result; #if defined(BOOST_WINDOWS) //#if defined(WIN32) if ( dest.root_name() != src.root_name() ) { // paths are on different drives (like, "c:/test/t.txt" and "d:/home") return dest; } if ( src_begin != src_end) ++src_begin; if ( dest_begin != dest_end) ++dest_begin; #endif // ignore directories that are same while ( (src_begin != src_end) && (dest_begin != dest_end)) { if ( *src_begin != *dest_begin) break; ++src_begin, ++dest_begin; } // now, we begin to relativize while ( src_begin != src_end) { result /= ".."; ++src_begin; } while ( dest_begin != dest_end) { result /= *dest_begin; ++dest_begin; } return result; } void test_relative_to( const std::string & dest, const std::string & src) { std::string result = relative_to( dest, src).string(); std::cout << "Testing path '" << dest << "',\n" " relative to '" << src << "'\n" " result : '" << result << "'\n" << std::endl; } int main(int argc, char* argv[]) { path::default_name_check( &native); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp/test"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp/test/other"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "c:/temp/test"); test_relative_to( "c:/temp/test", "c:/temp/test"); test_relative_to( "c:/temp/test/inner/i2/file.txt", "d:/temp/test"); test_relative_to( "c:/temp/test", "d:/temp/test"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/temp/test"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/oth/test/other"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/temp"); test_relative_to( "c:/other/test/inner/i2/file.txt", "c:/other/test"); return 0; } Best, John

2 2

Using Serialization for binary marshalling
by Matthew Vogt 22 Mar '04

22 Mar '04

Is anyone else interested in using Robert Ramey's serialization library for the purpose of marshalling data into pre-determined binary formats? This is not related to serialization in a general sense, but employing the syntax and underlying fundamentals of the library, to a somewhat related purpose. This is a test program demonstrating what I'm doing - I'm interested to know if anyone else is doing anything similar... Matt test.cpp: ------------------------------------------------------------------ #include <sstream> #include <cassert> #include "marshall.hpp" #include "network_oarchive.hpp" #include "network_iarchive.hpp" class test { struct subobject; // Basic fixed-size primitives uint8_t a; uint16_t b; uint32_t c; uint64_t d; // String data that must be serialized to a pre-determined length marshall::fixed_length<std::string, 20> e; marshall::fixed_length<std::wstring, 10> f; // String data that must be serialized with a prepended length // (whose size is itself predetermined) marshall::variable_length<std::string, uint8_t> g; marshall::variable_length<std::wstring, uint8_t> h; // Arbitrary data that must be serialized to a pre-determined length marshall::fixed_length<std::vector<uint16_t>, 5> i; marshall::fixed_length<std::vector<subobject>, 2> j; // Arbitrary data that must be serialized with a prepended length // (whose size is itself predetermined) marshall::variable_length<std::vector<uint16_t>, uint32_t> k; marshall::variable_length<std::vector<char>, uint32_t> l; // A sub-object of arbitrary complexity struct subobject { subobject(void) : a(0), b(0) {} subobject(uint32_t x, uint32_t y) : a(x), b(y) {} bool operator== (const subobject& other) const { return (a == other.a && b == other.b); } private: uint32_t a; uint32_t b; friend class boost::serialization::access; template <class Archive> void serialize(Archive& archive, const unsigned version) { archive & a & b; } }; friend class boost::serialization::access; template <class Archive> void serialize(Archive& archive, const unsigned version) { archive & a & b & c & d & e & f & g & h & i & j & k & l; } public: test(void) : a(0x01), b(0x0203), c(0x04050607), d(0x08090a0b0c0d0e0f), e("abcdefg"), g("xyz") { f[0] = 'A'; f[1] = 'B'; f[2] = 'C'; h.push_back('w'); i[0] = 255; i[1] = 254; i[2] = 253; j[0] = subobject(99, 100); k.push_back(1); k.push_back(2); k.push_back(3); l.push_back('l'); } test(bool) {} // Don't initialize everything bool operator== (const test& other) const { return (a == other.a && b == other.b && c == other.c && d == other.d && e == other.e && f == other.f && g == other.g && h == other.h && i == other.i && j == other.j && k == other.k && l == other.l); } }; int main(int, char**) { test t1; // Serialize object to binary format, in network byte order std::ostringstream oss; boost::archive::network_oarchive oa(oss); oa << t1; // Create uninitialized object test t2(false); // De-serialize object from binary format, in network byte order std::istringstream iss(oss.str()); boost::archive::network_iarchive ia(iss); ia >> t2; assert(t1 == t2); return 0; } This produces the following binary output: ------------------------------- 0000000 |01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 61 |a |b |c |d |e 0000020 |62 63 64 65 66 67 00 00 00 00 00 00 00 00 00 00 | 0000040 |00 00 00 00 00 00 41 00 00 00 42 00 00 00 43 00 | | f 0000060 |00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | 0000100 |00 00 00 00 00 00 00 00 00 00 00 03 78 79 7a 01 | |g |h 0000120 |00 00 00 77 00 ff 00 fe 00 fd 00 00 00 00 00 00 | |i |j 0000140 |00 63 00 00 00 64 00 00 00 00 00 00 00 00 00 00 | |k 0000160 |00 03 00 01 00 02 00 03 00 00 00 01 6c | |l

3 4

BOOST_PP_COMMA, LPAREN,RPAREN delay eval?
by Larry Evans 22 Mar '04

22 Mar '04

I've looked at some of the uses of these, but can't figure out how to do the following. Using boost/preprocessor macros, I want to generate code something like: #include <boost/mpl/vector.hpp> #include <boost/mpl/at.hpp> using namespace boost::mpl; struct source { target my_target ; template<typename VecOfTypes> source ( VecOfTypes const& , at_c<VecOfTypes,0>::type a0 ) : my_target ( a0 ) {} template<typename VecOfTypes> source ( VecOfTypes const& , at_c<VecOfTypes,0>::type a0 , at_c<VecOfTypes,1>::type a1 ) : my_target ( a0 , a1 ) {} }; and use it as follows: typedef vector<int,float> int_float_typelist; source s0(int_float_typelist(),0); source s1(int_float_typelist(),0,2.5); I was planning on defining a macro, PP_CTOR_FORWARDER_OVERLOAD, to be used as: struct source { BOOST_PP_REPEAT(2,PP_CTOR_FORWARDER_OVERLOAD,(source, my_target)) }; However, I also would like to use it where instead of my_target(a0,a1), there might be super_type(new target(a0,a1)), in which case the tuple that was the last arg to BOOST_PP_REPEAT would contain left and right parens. However, when I tried: BOOST_PP_REPEAT( 2, PP_CTOR_FORWARDER_OVERLOAD, (source,auto_ptr<target> BOOST_PP_LPAREN() new target, BOOST_PP_RPAREN() )) I get: /usr/local/gcc-3.4-20040225/bin/g++ -ggdb -c -Wall -MMD -O0 -ggdb -E -I/home/evansl/prog_dev/boost-root.ln/boost_dev -I/home/evansl/prog_dev/boost-root.ln pp_ctor_forwarder.cpp |indent -st pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_0" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_1" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_2" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_0" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_1" requires 4 arguments, but only 2 given pp_ctor_forwarder.cpp:4:1: macro "BOOST_PP_TUPLE_ELEM_4_2" requires 4 arguments, but only 2 given # 1 "pp_ctor_forwarder.cpp" How can I cause the delay in evaluation of BOOST_PP_RPAREN and LPAREN to avoid these errors? Here is my current macro def: #include "boost/preprocessor/enum_params.hpp" #include "boost/preprocessor/inc.hpp" #include "boost/preprocessor/punctuation/comma_if.hpp" #include "boost/preprocessor/tuple/elem.hpp" #define PP_CTOR_FORWARDER_PARAM(z,n,_) \ BOOST_PP_COMMA_IF(n) at_c<VecOfTypes,n>::type BOOST_PP_CAT(a,n) #define PP_CTOR_FORWARDER_OVERLOAD(z,n,data) \ template< typename VecOfTypes > \ BOOST_PP_TUPLE_ELEM(4,0,data) \ ( VecOfTypes const& \ , BOOST_PP_REPEAT(BOOST_PP_INC(n), PP_CTOR_FORWARDER_PARAM, BOOST_PP_EMPTY) \ ) \ : BOOST_PP_TUPLE_ELEM(4,1,data) \ BOOST_PP_ENUM_PARAMS(BOOST_PP_INC(n), a ) \ BOOST_PP_TUPLE_ELEM(4,2,data) \ {} TIA.

2 3

[BGL] transpose_graph documentation.
by Cromwell Enage 21 Mar '04

21 Mar '04

Accodring to <http://www.boost.org/libs/graph/doc/transpose_graph.html> the graph that will hold the transposition is supposed to have no edges in it and to have the same number of vertices as the input graph. However, looking through the source code in <boost/graph/copy.hpp>, which the algorithm uses, I see as many vertices being added to the output graph as there are in the input graph. Does this mean that the output graph is actually supposed to have no vertices to begin with? In the attached program, if the #if condition is set to 1, the program does as the documentation currently suggests, but the output is wrong. With the #if condition left at 0, the program gives the correct output. What's the verdict? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

2 1

[Filesystem] Relational operators
by Martin 21 Mar '04

21 Mar '04

I have used the filesystem library for some time now and I am really happy with it. In the CVS I noticed that it recently added relational operators and an "equivalent" function. To my surprice the relational operators are implemented in a non-portable way. It only does a lexicographical compare! In the rationale it says: "Programmers wishing to determine if two paths are "the same" must decide if that means "the same representation" or "resolve to the same actual file or directory", and choose the appropriate function accordingly." In windows the path "file.cpp" is the same as "FILE.CPP" but not in posix. So if I write portable code I need to do add a function like bool eq_path(const path& path1, const path& path2) { #if BOOST_POSIX return path1.string() == path2.string(); #else return boost::algorithm::iequals(path1.string(), path2.string()); #endif } In most of my cases the equivalent function is not an alternative since it requires that both paths can be evaluted by the filesystem, i.e. paths must exist and the parent of relative paths must be known. --------------------------------------- Another minor question: Why does the "leaf()" member function return a string and not a path?

2 1

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

21 Mar '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 21, 2004 9:02 pm Asunto: Re: [boost] Formal Review: Indexed Set [...] > > I was unable to unzip this file on Linux -- > > $ unzip indexed_set.zip > Archive: indexed_set.zip > End-of-central-directory signature not found. Either this file > is not > a zipfile, or it constitutes one disk of a multi-part archive. > In the > latter case the central directory and zipfile comment will be > found on > the last disk(s) of this archive. > ?? So weird, I've just downloaded it (in a Windows platform) and the file opens OK. I'll try to upload a tar.gz version tomorrow (I can't right now.) > Is the sandbox also up to date? It looks like there have been > recent changes > there. > Yes, it is up to date, though I prefer to refer people to the files section instead. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Little patch for static_assert.hpp
by Gennaro Prota 21 Mar '04

21 Mar '04

Hi John, apropos gcc's -Wundef :) The attached patch allows to compile static_assert.hpp with that option turned on. While I was at it I've also changed the license reference text and removed a spurious space at the end of the line that begins with 'agurt 15/sep/02:'. Maybe BOOST_BUGGY_INTEGRAL_CONSTANT_EXPRESSIONS could be removed too (replacing it with __BORLANDC__) PS: What's 'agurt'? -- Genny. begin 644 static_assert.hpp.diff M1FEL92!D:69F97)E;F-E(')E<&]R="!G96YE<F%T960@8GD@0U-$:69F(&)Y M($-O;7!O;F5N=%-O9G1W87)E(&]N(#(P+S`S+S(P,#0@,3DN,C`-"@T*0F%S M92!F:6QE.B!#.EQ$3T-5345^,5Q!1$U)3DE^,5Q)35!/4U1^,5Q496UP7'-T M871I8U]A<W-E<G1?;W)I9U\S+FAP<`T*0V]M<&%R960@9FEL93H@1#I<0U93 M(%)E<'-<8F]O<W1<8F]O<W1<8F]O<W1<8F]O<W1<8F]O<W1<<W1A=&EC7V%S M<V5R="YH<'`-"@T*,2PU8S$L-0T*/"`O+R`@*$,I($-O<'ER:6=H="!*;VAN M($UA9&1O8VL@,C`P,"X-"CP@+R\@(%5S92P@;6]D:69I8V%T:6]N(&%N9"!D M:7-T<FEB=71I;VX@87)E('-U8FIE8W0@=&\@=&AE(`T*/"`O+R`@0F]O<W0@ M4V]F='=A<F4@3&EC96YS92P@5F5R<VEO;B`Q+C`N("A3964@86-C;VUP86YY M:6YG(&9I;&4@#0H\("\O("!,24-%3E-%7S%?,"YT>'0@;W(@8V]P>2!A="!H M='1P.B\O=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0I#0H\(`T*+2TM M#0H^("\O("`@("`@("`@("`@*$,I($-O<'ER:6=H="!*;VAN($UA9&1O8VL@ M,C`P,"X-"CX@+R\@1&ES=')I8G5T960@=6YD97(@=&AE($)O;W-T(%-O9G1W M87)E($QI8V5N<V4L(%9E<G-I;VX@,2XP+@T*/B`O+R`@("`H4V5E(&%C8V]M M<&%N>6EN9R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T#0H^("\O M("`@("`@("`@(&AT='`Z+R]W=W<N8F]O<W0N;W)G+TQ)0T5.4T5?,5\P+G1X M="D-"CX@+R\-"C8Q8S8Q#0H\("`@("`A0D]/4U1?5T]22T%23U5.1"A?7TU7 M15)+4U]?+"`\(#!X,S`P,RD-"BTM+0T*/B`@("`@(2AD969I;F5D(%]?35=% M4DM37U\@)B8@0D]/4U1?5T]22T%23U5.1"A?7TU715)+4U]?+"`\(#!X,S`P M,RDI#0HW-F,W-@T*/"`O+R!A9W5R="`Q-2]S97`O,#(Z(&$@<W!E8VEA;"!C M87)E(&ES(&YE961E9"!T;R!F;W)C92!);G1E;"!#*RL@:7-S=64@86X@97)R M;W(@#0HM+2T-"CX@+R\@86=U<G0@,34O<V5P+S`R.B!A('-P96-I86P@8V%R M92!I<R!N965D960@=&\@9F]R8V4@26YT96P@0RLK(&ES<W5E(&%N(&5R<F]R M#0H-"@T*/"TM+2TM+2TM+2TM+2TM+2TM+2TM+2`@16YD(&]F(')E<&]R="`@ :+2TM+2TM+2TM+2TM+2TM+2TM+2TM/@T*#0HM ` end

2 3

[utility] enable_if request
by Jonathan Turkanis 21 Mar '04

21 Mar '04

Hi, Often I use enable_if and its cousins to add functionality to code which works okay on compilers without SFINAE. So I have a lot of code which looks like this: template<typename T> #ifndef BOOST_NO_SFINAE typename enable_if<is_xxx<T>, int>::type #else int #endif f(T t); or template<typename T> void f( T t #ifndef BOOST_NO_SFINAE , typename enable_if<is_xxx<T>, int>::type* = 0 #endif ); It would be nice to have macros BOOST_ENABLE_IF_RETURN(condition, result) and BOOST_ENABLE_IF_PARAM(condition) so that the above could be written template<typename T> BOOST_ENABLE_IF_RETURN(is_xxx<T>, void) f(T); template<typename T> void f(T BOOST_ENABLE_IF_PARAM(is_xxx<T>)); (And similarly for enable_if_c, etc.) It's straightforward to write macros which work for conditions which don't need to be enclosed in parentheses; e.g.: #ifndef BOOST_NO_SFINAE # define BOOST_ENABLE_IF_RETURN(condition, result) \ typename boost::enable_if<condition, result>::type #else # define BOOST_ENABLE_IF_RETURN(condition, result) result #endif With a little more work, you can allow use such as template<typename T, typename U> BOOST_ENABLE_IF_RETURN((is_base_and_derived<T, U>), void) f(T, U); e.g. #define BOOST_ENABLE_IF_RETURN(condition, result) \ typename boost::enable_if< \ typename boost::function_traits< \ void condition \ >::arg1_type, result \ >::type Here the parentheses in the macro invocation are required. (I've found I can make the parentheses in the macro invocation optional by surrounding 'condition' in the above #define with parentheses -- 'void(condition)' -- but I'm not sure this is standard conforming. It does work on a lot of good compilers, though.) Any thoughts? Jonathan

1 0

RE: [boost] Boost.Spirit comments and stuff
by Reece Dunn 21 Mar '04

21 Mar '04

Hartmut Kaiser wrote: >Reece Dunn wrote: > > [4] I am now making use of boost::spirit::sub_grammar from > > libs/spirit/doc/techniques.html. One thing I get from this is > > that the typedef for the grammar type can be very difficult > > to read, especially for non-trivial grammars! I have started > > writing a set of type helpers to simplify the process: > >[snip] > > > If there is interest, I shall create a proper submission for them. > >Nice idea. Do you want to submit a patch for the >libs/spirit/doc/techniques.html file? I am not sure about a patch to the techniques.html file, maybe you or Joel want to add a comment. The idea was to have the type constructors as a helper file to be used in conjunction with sub_grammar, or when building any non-rule<> (explicitly typed) rule. It contains some of the more common combinations, and can be used (using the skip_parser example) like: typedef boost::spirit::alternative_t < boost::spirit::space_parser, boost::spirit::line_comment, boost::spirit::range_comment >::type start_t; Including the entire set into the HTML file would be too distracting. A link would probably be best with a few of the classes as an example. NOTE: I have made a revision to alternative3_t so it is now a 2-4 -ary construct (it is easy to extend this to support more if there is a need) using mpl :). I have also added some more constructs that might be useful. Here is a more complex example using my helpers: struct number_parser: public boost::spirit::sub_grammar< number_parser > { public: typedef boost::spirit::contiguous_sequence_t < boost::spirit::alternative_t < boost::spirit::sequence < boost::spirit::strlit_nocase_t<>::type, boost::spirit::hex_t >, boost::spirit::sequence < boost::spirit::chlit<>, boost::spirit::oct_t >, boost::spirit::real_t<>::type >::type, boost::spirit::kleene_star< boost::spirit::chset_nocase_t<>::type > >::type start_t; public: start_t start; public: inline number_parser(): start ( boost::spirit::lexeme_d [ ( boost::spirit::as_lower_d[ "0x" ] >> boost::spirit::hex_p | '0' >> boost::spirit::oct_p | boost::spirit::real_p ) >> *boost::spirit::as_lower_d[ boost::spirit::chset_p( "ldfu" )] ] ) { } } number; Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Boost.Spirit comments and stuff
by Reece Dunn 20 Mar '04

20 Mar '04

I have been learning Boost.Spirit over the past few days and here are a few queries: [1] Is it possible to process a token stream rather than a character stream? If so, are there any examples? The reason I am asking is... [2] Is it possible to cascade spirit grammars, e.g. wave.parse() >> cpp.parse(); // hypothetical where the output of the wave grammar feeds the token stream of the cpp grammar. I am not propsing that the above is how this would be expressed. [3] Is it possible to combine the file_iterator with the position_iterator to provide error reporting on that? [4] I am now making use of boost::spirit::sub_grammar from libs/spirit/doc/techniques.html. One thing I get from this is that the typedef for the grammar type can be very difficult to read, especially for non-trivial grammars! I have started writing a set of type helpers to simplify the process: namespace boost { namespace spirit { template< typename T1, typename T2, typename T3 > struct alternative3_t { typedef alternative< alternative< T1, T2 >, T3 > type; }; template< typename T1, typename T2, typename T3 > struct sequence3_t { typedef sequence< sequence< T1, T2 >, T3 > type; }; // confix_type = T1 >> *( CompositeT - T2 ) >> T2 template< typename CompositeT, typename T1 = strlit< const char * >, typename T2 = T1 > struct confix_t { typedef typename sequence3_t < T1, kleene_star< difference< CompositeT, T2 > >, T2 >::type type; }; template< typename T2 = strlit< const char * >, typename T1 = strlit< const char * > > struct comment_t { typedef typename confix_t< anychar_parser, T1, T2 >::type type; }; typedef comment_t< chlit< char > >::type line_comment; typedef comment_t<>::type range_comment; }} using these, the typedef for the skip_grammar example becomes: typedef typename boost::spirit::alternative3_t < boost::spirit::space_parser, boost::spirit::line_comment, boost::spirit::range_comment >::type start_t; If there is interest, I shall create a proper submission for them. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 2

RE: [boost] Re: [config] Patch for Intel 8.0 + Dinkum lib
by Reece Dunn 20 Mar '04

20 Mar '04

Gennaro Prota wrote: >My goal was to choose short names, as otherwise preprocessing lines >easily become enormous (if nothing else, it's a boost guideline to not >exceed 80 characters). Note that even things like: > > #if BOOST_MSVC >= 1200 > >are usually rewritten as > > #if defined(BOOST_MSVC) && BOOST_MSVC >= 1200 > >just because gcc warns about the first form when using -Wundef. And >something like > >#if defined(BOOST_GCC_CXX_VERSION) && BOOST_GCC_CXX_VERSION >= 295 > >is already 66 characters. Isn't there a BOOST_WORKAROUND macro for this? e.g. #if BOOST_WORKAROUND( BOOST_MSVC, >= 1200 ) #if BOOST_WORKAROUND( BOOST_GCC_CXX_VERSION, >= 295 ) Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

sregex_token_iterator bug?
by Stephan T. Lavavej 20 Mar '04

20 Mar '04

gcc 3.3.3 with boost 1.31.0 on GNU/Linux: [3/19/2004 Fri 8:16.41 PM stl@nuwen ~/boost] [14 33 47] > cat moo.cc #include <iostream> #include <string> #include <boost/regex.hpp> using namespace std; using namespace boost; int main() { string s; getline(cin, s); sregex_token_iterator i(s.begin(), s.end(), regex("\\s+"), -1); cout << "x" << *i << "x" << endl; ++i; cout << "x" << *i << "x" << endl; ++i; cout << "x" << *i << "x" << endl; } [3/19/2004 Fri 8:16.46 PM stl@nuwen ~/boost] [14 33 47] > g++ -Wall -W moo.cc -o moo -lboost_regex [3/19/2004 Fri 8:16.57 PM stl@nuwen ~/boost] [14 33 47] > moo 1 2 3 x1x Segmentation fault [3/19/2004 Fri 8:17.01 PM stl@nuwen ~/boost] [14 33 47] > However, the first example given in http://boost.org/libs/regex/doc/regex_token_iterator.html works fine, so I don't know what's going on. Stephan T. Lavavej http://nuwen.net

2 1

[Boost-bugs] [ boost-Bugs-920003 ] Filesystem bug with rename
by SourceForge.net 20 Mar '04

20 Mar '04

Bugs item #920003, was opened at 2004-03-20 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=920003&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Adrian (wpcmame) Assigned to: Nobody/Anonymous (nobody) Summary: Filesystem bug with rename Initial Comment: There is a bug in the windows version of filesystem::rename. In the documentation it says: ----- Source: !is_directory() Target: is_directory() The source file is moved to the target directory. ---- The problem is that the function used "::MoveFileA" will either rename a file or a directory but it will not move a file to a directory. (Error "target already exists") To move a file, the filname must also be in the target path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=920003&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] minor problem with docs
by Jonathan Turkanis 19 Mar '04

19 Mar '04

The acknowledgements for filesystem/exception.hpp say "Peter Dimov patently identified requirements for portability and internationalization of error messages." I have a feeling this should say 'patiently.' I suppose 'patently' also makes sense here, but it seems a strange choice of words. Jonathan

2 1

[filesystem] windows bug
by John Torjo 19 Mar '04

19 Mar '04

On a windows system, doing this: path::default_name_check( &windows_name); path p( "c:/temp/test"); Throws an exception. However, having: path::default_name_check( &native); path p( "c:/temp/test"); works. I think there is a bug in path_posix_windows.cpp, line 241: if ( (checker == no_check || checker == native) && src.size() >= 2 ) I guess it should be something like: if ( (checker == no_check || checker == native || check == windows_name) && src.size() >= 2 ) Best, John

2 1

RE: [boost] [program_options] post-review version
by Hanson, Iain 19 Mar '04

19 Mar '04

Hi, > The library and documentation can be obtained at > > http://zigzag.cs.msu.su:7813/program_options > [ snip ... ] Is there any chance that you can put these on a url that does not use a port number. I sit behind a firewall that will not allow me to view these. Alternatively, would it be possible for you to put it in the sandbox? Thanks & regards /ikh ============================================================================== 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

[signal] documentation
by John Torjo 19 Mar '04

19 Mar '04

Hi All, Why does the documentation of boost::signal go to the web? (more specifically, http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/signals.html) I would like to have it locally, as the rest of the docs. Best, John

2 1

Boost Regex Doc Buglet
by Stephan T. Lavavej 19 Mar '04

19 Mar '04

http://boost.org/libs/regex/doc/syntax.html > Set declarations that start with "^" contain the compliment > of the elements that follow. Complement. Stephan T. Lavavej http://nuwen.net

2 1

RE: [boost] Re: recommend logging library?
by Simon J. Julier 19 Mar '04

19 Mar '04

I'm very interested in the question of logging libraries as well. >There are a few log4J ones out there. I've been using Log4cplus from >sourceforge and a been happy enough with it for its simple purpose. I personally agree. I've tried various different logging strategies including various types of macros and globally set log levels. However, I typically find that those approaches don't provide a sufficiently fine-grained approach when I debug code. (e.g., I might want some code to be hyperverbose and other bits to remain quiet). I like the additivity, hierarchical logger strategies of log4J et al. because they given a fairly fine-grained control over what gets logged and how. I've personally been using log4cpp (looks almost like log4cplus). It has two solutions to the issue of the cost of logging a message: 1. You can query the logger to see if the message would be logged if it were generated. Therefore, you can do things like: if (logger.isDebugEnabled()) logger.getDebugStream() << message ; (the stream support leaves a lot to be desired) 2. You can also log messages using printf-style commands: logger.debug("%s", message); These don't get evaluated unless the message is logged. Cheers, Simon

1 0

RE: [boost] Re: Trying to do something like boost::python for Net scapesSpiderMon key JavaScript engine
by Warrick Buchanan 19 Mar '04

19 Mar '04

I also stumbled across CliPP a few days ago and have been examining it somewhat but unfortunately the interpreter is not yet completely finished but I'm certainly going to keep an eye on that one :) Thanks, Warrick. -----Original Message----- From: Fredrik Blomqvist [mailto:fredrik_blomqvist@home.se] Sent: 18 March 2004 23:33 To: boost(a)lists.boost.org Subject: [boost] Re: Trying to do something like boost::python for NetscapesSpiderMon key JavaScript engine Warrick Buchanan wrote: > Hi, > > As the subject says I'm trying to a boost::python like equivalent for > SpiderMonkey (Netscape's JavaScript engine) and I've been trying(!) > to look at boost::python for inspiration. I've got to the stage > where I can quite happily expose a class like so: > > // D3D's Vector class just for example > Declare<D3DXVECTOR>::Property<0>("x", &D3DXVECTOR3::x); // 0 is > 'tinyid' Declare<D3DXVECTOR>::Property<1>("y", &D3DXVECTOR3::y); // 1 > is 'tinyid' Declare<D3DXVECTOR>::Property<2>("z", &D3DXVECTOR3::z); > // 2 is 'tinyid' Declare<D3DXVECTOR>::Definition("Vector3", > jsContext, jsObject, > jsPrototype); > > Just from those four lines you can then use the C++ class in > JavaScript without issue ie: > > var v = new Vector3(); > > v.x = 4.0f; > ...etc... > > Now I want to expose methods and constructors. Originally I was > planning to have a load of templates for each number of arguments a > function could possibly take (which obviously isn't ideal), but > looking at boost::python it seems it has a more elegant but currently > illegible to me way of doing this? Has anyone got any pointers to how > this works or comments that would help my understanding? > This isn't really my domain but I recently stumbled into a lib called CliPP http://clipp.sourceforge.net by Peder Holt. It claims to do Javascript-style C++ bindings. It seems quite "boostified" also, with connection to boost::spirit and, obviously boost::python. Might give you some ideas if nothing else. Regards // Fredrik Blomqvist _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

binding to collections
by John Torjo 19 Mar '04

19 Mar '04

Dear boosters, Right now, you need to type pretty much if you want to bind, lets say to the key or value from a collection. Example: typedef std::map<int,std::string> map; bind(&map::value_type::first,_1); // bind to key bind(&map::value_type::second,_1); // bind to value I've made two utility classes, in order to lessen the amount of typing. Also, an example is provided. #include <boost/bind.hpp> #include <map> #include <string> #include <iostream> namespace boost { namespace coll { template< class coll_type> struct key { typedef typename coll_type::value_type pair; typedef typename pair::first_type result_type; result_type operator()( const pair & p) { return p.first; } }; template< class coll_type> struct val { typedef typename coll_type::value_type pair; typedef typename pair::second_type result_type; result_type operator()( const pair & p) { return p.second; } }; }} void print_int( int i) { std::cout << i << std::endl; } void print_str( const std::string & s) { std::cout << s << std::endl; } int main(int argc, char* argv[]) { typedef std::map<int,std::string> map; map m; m[1] = "one"; m[2] = "two"; m[3] = "three"; using namespace boost; using namespace boost::coll; // using key & val utility classes std::for_each( m.begin(), m.end(), bind( print_int, bind(key<map>(),_1)) ); // bind to key std::for_each( m.begin(), m.end(), bind( print_str, bind(val<map>(),_1)) ); // bind to val // how you can bind to key or value from a collection, now std::for_each( m.begin(), m.end(), bind( print_int, bind(&map::value_type::first,_1)) ); std::for_each( m.begin(), m.end(), bind( print_str, bind(&map::value_type::second,_1)) ); return 0; } Best, John

1 0

Re: compiling error using boost::fsm by Andreas Huber
by Ahmed Ali 19 Mar '04

19 Mar '04

>boost::fsm currently does not work with any version of MSVC before 7.1 and >probably never will. Very early versions of boost::fsm did support VC7.0 >but I >had to drop it because I kept running into the weirdest compilation >problems. >Most of them were due to the notorious ETI bug. > >Sorry, > >Andreas thats mean I must upgrade? ot it can be fixed with patch? _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

2 1

[filesystem] recursive iteration
by Thorsten Ottosen 19 Mar '04

19 Mar '04

Hi Beman, I just had a look at boost::filesystem, and it felt really good to use. There is one common idiom that might be worth including: recursive traversal. So I would like some like recursive_directory_iterator i( path( "foo" ) ) , end; for( i.set_traversal_mode( files_only ); i != end; ++ i ) // print all file names recursively, default could be both dirs and files cout << i->leaf(); My motivation for this is that 1. the manual implementation of the recursion can require a bit tweaking to get right 2. other languages seem to provide such features, eg. os.walk() in python. If people like the idea, I can provide a starting point implementation. br Thorsten

6 8

RE: [boost] Re: recommend logging library?
by Hurd, Matthew 19 Mar '04

19 Mar '04

I'll add $0.02 to the conversation. Logging for me depends on the infrastructure you need the logs for. The output needs to be suitable. Two main styles I see are SNMP and Log4J style. This means app logging can interoperate. Forgetting about SNMP for the time being, I'd look at the cpp log4J clones. They support things like syslog, NT event log, files, ip messaging output with different styles of formatting. There are a few log4J ones out there. I've been using Log4cplus from sourceforge and a been happy enough with it for its simple purpose. Being able to have zero overhead for compiling it outta-there and having enabling and disabling at run-time would be nice. The other thing I'd like is having support for stack viewing which I've used in the past for helping with production support. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 2

Inactive Objects
by scott 19 Mar '04

19 Mar '04

Hi to those folks that contributed to some recent messages related to threads, active objects and reactive objects. Mostly this was Matthew Vogt. So this is mostly for Matthew but anyone else can certainly respond. I have been interested in proposing an alternative threading model to that provided by boost.threads. Quite sensibly somone suggested that any alternative should leverage the existing facillity. J. Garland also provided the reference to the work of Schmidt; the ActiveObject pattern. I have been trying to slice off a piece of a larger library that I have been working on. Defining something that would be appropriate as a proposal to boost is very difficult. I started a requirements document to that end which become more of a research paper. Its convinced me that it is probably a no-go. The fundamental reason would be the scope of anything with pretentions to calling itself "active objects". It requires not only a significant body of supporting code but requires quite a cultural change by users (i.e. developers). I would have posted the document but it is quite long. If anyone is interested in it then just ask for it. Its a rambling piece but it has been reviewed :-) Cheers, Scott

4 4

[OT] AspectC++ 0.8 (Stable)
by Neal Becker 19 Mar '04

19 Mar '04

This may interest some of you: http://freshmeat.net/projects/aspectc/?branch_id=41657&release_id=154775

1 0

Trying to do something like boost::python for Netscapes SpiderMon key JavaScript engine
by Warrick Buchanan 18 Mar '04

18 Mar '04

Hi, As the subject says I'm trying to a boost::python like equivalent for SpiderMonkey (Netscape's JavaScript engine) and I've been trying(!) to look at boost::python for inspiration. I've got to the stage where I can quite happily expose a class like so: // D3D's Vector class just for example Declare<D3DXVECTOR>::Property<0>("x", &D3DXVECTOR3::x); // 0 is 'tinyid' Declare<D3DXVECTOR>::Property<1>("y", &D3DXVECTOR3::y); // 1 is 'tinyid' Declare<D3DXVECTOR>::Property<2>("z", &D3DXVECTOR3::z); // 2 is 'tinyid' Declare<D3DXVECTOR>::Definition("Vector3", jsContext, jsObject, jsPrototype); Just from those four lines you can then use the C++ class in JavaScript without issue ie: var v = new Vector3(); v.x = 4.0f; ...etc... Now I want to expose methods and constructors. Originally I was planning to have a load of templates for each number of arguments a function could possibly take (which obviously isn't ideal), but looking at boost::python it seems it has a more elegant but currently illegible to me way of doing this? Has anyone got any pointers to how this works or comments that would help my understanding? Thanks, Warrick

2 1

mem_fn warnings
by David Abrahams 18 Mar '04

18 Mar '04

I keep getting lots of these: c:\boost\boost\mem_fn.hpp(264) : warning C4180: qualifier applied to function type has no meaning; ignored Would it be possible for the mem_fn header to #pragma push a warning disabler for MSVC? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

RE: [boost] Trying to do something like boost::python for Netscap es SpiderMon key JavaScript engine
by Warrick Buchanan 18 Mar '04

18 Mar '04

Aaah and I've just noticed that boost::python uses the boost preprocessor stuff that I think does effectively through macros generate a load of templates for up to a constant N number of templated function arguments - and am I right in that this mad preprocessor stuff it recursively includes itself? eeek(!) -----Original Message----- From: Warrick Buchanan [mailto:Warrick@argonaut.com] Sent: 18 March 2004 10:44 To: 'boost(a)lists.boost.org' Subject: [boost] Trying to do something like boost::python for Netscapes SpiderMon key JavaScript engine Hi, As the subject says I'm trying to a boost::python like equivalent for SpiderMonkey (Netscape's JavaScript engine) and I've been trying(!) to look at boost::python for inspiration. I've got to the stage where I can quite happily expose a class like so: // D3D's Vector class just for example Declare<D3DXVECTOR>::Property<0>("x", &D3DXVECTOR3::x); // 0 is 'tinyid' Declare<D3DXVECTOR>::Property<1>("y", &D3DXVECTOR3::y); // 1 is 'tinyid' Declare<D3DXVECTOR>::Property<2>("z", &D3DXVECTOR3::z); // 2 is 'tinyid' Declare<D3DXVECTOR>::Definition("Vector3", jsContext, jsObject, jsPrototype); Just from those four lines you can then use the C++ class in JavaScript without issue ie: var v = new Vector3(); v.x = 4.0f; ...etc... Now I want to expose methods and constructors. Originally I was planning to have a load of templates for each number of arguments a function could possibly take (which obviously isn't ideal), but looking at boost::python it seems it has a more elegant but currently illegible to me way of doing this? Has anyone got any pointers to how this works or comments that would help my understanding? Thanks, Warrick _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Is there any interest in this container?
by Peter Palotas 18 Mar '04

18 Mar '04

I was wondering if there is any interest in a container that is a model of sequence (just like std::vector or std::list) and with an interface matching that of std::vector (maybe with minor differences due to effiency) but with different time complexities? Basically this is a Random Access Container but with the following time complexity guarantees instead: * insert/erase anywhere in the list: O(lg n) * element Access (i.e. [] or at()): O(lg n) * front()/back(): O(1) This would make it better than a list for random accessing elements and better than a vector for inserting/deleting elements in the middle of the list. I am currently working of an implementation of this container and thought I would see if there would be any interest in such a container from the boost community. Sincerely, Peter Palotas

7 18

64-bit IRIX build problems with Boost 1.31.0
by Patrick Hartling 18 Mar '04

18 Mar '04

I am trying to make a 64-bit build of Boost 1.31.0 on IRIX using the MIPSpro Compilers 7.3.1.3m, but I cannot seem to get any of the dynamic libraries to link. The bjam command line I am using is this: bjam -sTOOLS=mipspro "-sBUILD=debug release <runtime-link>static/dynamic <address-model>64" (I have $PYTHON_ROOT pointing to a 64-bit build of Python 2.2.3.) All link actions for dynamic libraries fail thusly: ld64: FATAL 12 : Expecting n64 objects: /usr/lib32//c++init.o is n32. Looking at the output after the failed action, I see -L/usr/lib32 in the link line, and I am pretty sure it should not be there. The complete output of the first failed action is this: "/usr/bin/CC" \ -o "bin/boost/libs/date_time/build/libboost_date_time.so/mipspro/debug/address-model-64/libboost_date_time-mp-d-1_31.so" \ "bin/boost/libs/date_time/build/libboost_date_time.so/mipspro/debug/address-model-64/greg_month.o" "bin/boost/libs/date_time/build/libboost_date_time.so/mipspro/debug/address-model-64/greg_weekday.o" "bin/boost/libs/date_time/build/libboost_date_time.so/mipspro/debug/address-model-64/date_generators.o" \ \ "-DBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG" "-DBOOST_ALL_DYN_LINK=1" \ "-nostdinc" "-LANG:std" "-OPT:Olimit=0" "-OPT:IEEE_NaN_inf=ON" "-no_auto_include" "-64" "-mips3" "-O0" "-g" "-INLINE:none" \ \ \ "-I/usr/include/CC" "-I//usr/include/CC" "-I/mnt/rigby/home13/users/patrick/src/Boost/blah/boost_1_31_0/boost/compatibility/cpp_c_headers" \ "-I/usr/include" "-I//usr/include" "-I/mnt/rigby/home13/users/patrick/src/Boost/blah/boost_1_31_0" \ "-nostdlib" "-shared" \ \ \ \ "-L/usr/lib32/mips3" "-L/usr/lib32/" "-L//usr/lib32/mips3" "-L//usr/lib32/" "-L/usr/lib32/mips3" "-L/usr/lib32/" "-L//usr/lib32/mips3" "-L//usr/lib32/" "-L/usr/lib64/mips3" "-L/usr/lib64/" "-L//usr/lib64/mips3" "-L//usr/lib64/" \ "-lm" All the object files being linked in this case are 64-bit, so I think that the compile action is behaving correctly. Am I forgetting something in my bjam command or otherwise misusing bjam? -Patrick -- Patrick L. Hartling | Research Assistant, VRAC patrick(a)vrac.iastate.edu | 2274 Howe Hall Room 2624 http://www.vrac.iastate.edu/~patrick/ | http://www.vrac.iastate.edu/ PGP: http://wwwkeys.gpg.cz:11371/pks/lookup?op=get&search=0xEBF86398

1 0

VC++ boost.Thread library usage ?
by raja 18 Mar '04

18 Mar '04

Hi, I am getting the following error. I see that it is trying to link to the static library, but I still get this error. Would appreciate if someone can correct my usage. Linking to lib file: lib"boost_thread"-vc71-mt-sgd-1_31.lib c:\Boost\include\boost-1_31\boost\config\auto_link.hpp(269) : fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." Here is my sample: #define _MSC_VER 1310 #define BOOST_LIB_NAME "boost_thread" #define BOOST_LIB_DIAGNOSTIC "on"// Show library file details. #include <boost/config/auto_link.hpp> #include <boost/thread/thread.hpp> #include <iostream> void hello() { std::cout << "Hello world, I'm a thread!" << std::endl; } int main(int argc, char* argv[]) { boost::thread thrd(&hello); thrd.join(); return 0; }

6 6

compiling error using boost::fsm by Andreas Huber VC7.0
by Ahmed Ali 18 Mar '04

18 Mar '04

The solution was for vc7.1 but i have vc7.0 and i got these errors from contructor.h C:\Boost\include\boost-1_31\boost\fsm\detail\constructor.hpp(42): error C2039: 'context_ptr_type' : is not a member of 'operator``global namespace''' C:\Boost\include\boost-1_31\boost\fsm\detail\constructor.hpp(42): error C2825: 'boost::fsm::detail::outer_constructor<ContextList,OutermostContext>::to_construct::context_ptr_type': cannot form a qualified name C:\Boost\include\boost-1_31\boost\fsm\detail\constructor.hpp(42): fatal error C1507: previous user errors and subsequent error recovery halt further compilation _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

compiling error using boost::fsm by Andreas Huber VC7.0
by Ahmed Ali 18 Mar '04

18 Mar '04

The solution was for vc7.1 but i have vc7.0 and i got these errors from contructor.h C:\Boost\include\boost-1_31\boost\fsm\detail\constructor.hpp(42): error C2039: 'context_ptr_type' : is not a member of 'operator``global namespace''' C:\Boost\include\boost-1_31\boost\fsm\detail\constructor.hpp(42): error C2825: 'boost::fsm::detail::outer_constructor<ContextList,OutermostContext>::to_construct::context_ptr_type': cannot form a qualified name C:\Boost\include\boost-1_31\boost\fsm\detail\constructor.hpp(42): fatal error C1507: previous user errors and subsequent error recovery halt further compilation _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

filesystem::path assigment operator question
by Janusz Piwowarski 18 Mar '04

18 Mar '04

Hello There isn't defined path assigment operator, is it intentional? Implementation uses default one. Regards, Janusz

2 2

[Boost-bugs] [ boost-Bugs-918570 ] 1.31.0 doesn't support inter-win32-stlport use intel8.0
by SourceForge.net 18 Mar '04

18 Mar '04

Bugs item #918570, was opened at 2004-03-17 23:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918570&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 1.31.0 doesn't support inter-win32-stlport use intel8.0 Initial Comment: can't get compile! maybe the bug of stlport! because stlport4.6.1 can't been compiled by intel c++8.0! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=918570&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

enumeration interface for boost::signals
by E. Gladyshev 18 Mar '04

18 Mar '04

Does boost::signals have a public enumeration interface (like iterator concept) that can be used for accessing individual slots? There is some mention of it in the "Slot Call Iterator" section but not much detailed. For instance, what I'd like is to call a slot and depending on the result call some other slot. A related question is if I have an instance of boost::signals::connection, is it possible to get an access to the slot that this connection is referencing? Thanks, Eugene

5 21

Spirit file_iterator with windows/unicode
by Reece Dunn 18 Mar '04

18 Mar '04

When using <boost/spirit/iterator/file_iterator.hpp> with windows when UNICODE is defined, the following: file_iterator<> file( "foobar.txt" ); will fail to compile since the call to ::CreateFile in <boost/spirit/iterator/impl/file_iterator.ipp> line 182 maps to CreateFileW and not CreateFileA which is wanting a wide-character filename. The solution is thus: <boost/spirit/iterator/impl/file_iterator.ipp> line 182: - HANDLE hFile = ::CreateFile( + HANDLE hFile = ::CreateFileA( Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Missing symbols from the Boost.Signals DLL's
by Nicola Musatti 17 Mar '04

17 Mar '04

Hallo, After building Boost 1.31 with the borland toolset I noticed that some symbols were missing from the Boost.Signals DLL's. More specifically all the symbols exported from libs/signals/src/signal_base.cpp are not exported. This appears to be caused by the explicit inclusion of boost/signals/detail/config.hpp in boost/signals/detail/signal_base.hpp. The effect of this inclusion is to miss the indirect inclusion of boost/config.hpp . After removing the #include <boost/signals/detail/config.hpp> line from signal_base.hpp the DLL's build correctly. Note that while I only tested with the borland toolset this problem is potentially present on all the win32 toolsets. Cheers, Nicola Musatti

2 1

RE: [boost] Is there any interest in this container?
by Peter Palotas 17 Mar '04

17 Mar '04

> >>> peter(a)smartbusiness.nu 03/16/04 03:49PM >>> wrote: > > I was wondering if there is any interest in a container that is a > > model of sequence (just like std::vector or std::list) and with an > > interface matching that of std::vector (maybe with minor > differences > > due to efficiency) but with different time complexities? > > On a related note, all the basic associative containers could > (and arguably should) have an "nth_element" method with > complexity O(log(n)). With this interface addition a > container with an interface like vector but complexity like > map could be adapted from map akin to the way queue is > adapted from deque. Are you suggesting a change in the implementation of the standard sorted associative containers? I'm not sure that would be a good idea, since maintaining information in them to find the nth element in O(log n) time would add an overhead to insert/delete operations which would be undesirable if you don't need that functionality, which in fact I think you normally don't. Just a thought. // Peter Palotas

1 0

Re: [boost] Is there any interest in this container?
by Jesse Booher 17 Mar '04

17 Mar '04

>>> peter(a)smartbusiness.nu 03/16/04 03:49PM >>> wrote: > I was wondering if there is any interest in a container that is a model of > sequence (just like std::vector or std::list) and with an interface matching > that of std::vector (maybe with minor differences due to efficiency) but with > different time complexities? On a related note, all the basic associative containers could (and arguably should) have an "nth_element" method with complexity O(log(n)). With this interface addition a container with an interface like vector but complexity like map could be adapted from map akin to the way queue is adapted from deque. Just a thought. Jesse Booher

1 0

Indexed set: reverse
by Darren Cook 17 Mar '04

17 Mar '04

I tried indexed_set with g++ 3.2.3 ("gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)") and it compiled all the examples. The reference docs need an "up" link (back to libs/indexed_set/doc/index.html). Your tutorial did not deal with using an index in reversed order; I think it is worth adding something showing using rbegin()/rend() (I modified basic.cpp to print ages oldest first and it worked first time :-). I found a reverse() function in sequenced.cpp: it seems you apply this to the indexed_set container, not to the index, but when I tried it on the container in basic.cpp I get a compile error. So I tried the sequenced example using rbegin/rend and it worked: tc.reverse(); std::copy(tc.begin(),tc.end(), std::ostream_iterator<std::string>(std::cout," ")); tc.reverse(); /* undo */ std::copy(tc.rbegin(),tc.rend(), std::ostream_iterator<std::string>(std::cout," ")); Can you explain the thinking behind reverse()? Is it any more/less efficient than using rbegin/rend? If not, I think it should either be dropped or extended to regular indices as well. Darren Joaquín Mª López Muñoz wrote: > For those interested in indexed_set, release 9 is available at: > > http://groups.yahoo.com/group/boost/files/indexed_set.zip > > the sandbox version is not in sync, it'll be by tomorrow.

2 3

autolink should not require MSC language extensions
by Paul A Bristow 16 Mar '04

16 Mar '04

Recently I puzzled why autolink did not work for some programs. After some stumbling about, I realised that this was because _MSC_EXTENSIONS is a required definition (as well as MSVC). I can't see why this should be - autolink works perfectly well regardless of the compiler setting chosen. (But I can see why most people will not see this - because MS require the language extensions). But I suggest that in autolink.hpp #if (defined(BOOST_MSVC) && defined(_MSC_EXTENSIONS)) can helpfully be replaced by #if (defined(BOOST_MSVC)) for those whose preferences are for strictness'. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

2 2

missing pthread_mutexattr_destroy in boost thread (V 1.31.0)
by Adrian 16 Mar '04

16 Mar '04

Dear William I think you have missed pthread_mutexattr_destroy() in recursive_mutex::recursive_mutex() and recursive_mutex::recursive_try_mutex(). Proposed patch: #elif defined(BOOST_HAS_PTHREADS) recursive_mutex::recursive_mutex() : m_count(0) # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) , m_valid_id(false) # endif { pthread_mutexattr_t attr = 0; int res = 0; res = pthread_mutexattr_init(&attr); assert(res == 0); # if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); assert(res == 0); # endif res = pthread_mutex_init(&m_mutex, &attr); pthread_mutexattr_destroy(&attr); /* missing */ if (res != 0) throw thread_resource_error(); ../.. recursive_try_mutex::recursive_try_mutex() : m_count(0) # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) , m_valid_id(false) # endif { pthread_mutexattr_t attr = 0; int res = 0; res = pthread_mutexattr_init(&attr); assert(res == 0); # if defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); assert(res == 0); # endif res = pthread_mutex_init(&m_mutex, &attr); pthread_mutexattr_destroy(&attr); if (res != 0) throw thread_resource_error(); ___________________________________________________ Yahoo! Messenger - Nueva versión GRATIS Super Webcam, voz, caritas animadas, y más... http://messenger.yahoo.es

2 1

RE: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 16 Mar '04

16 Mar '04

> -----Original Message----- > From: Peter Dimov [mailto:pdimov@mmltd.net] > Sent: Friday, March 12, 2004 12:24 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Explicit instantiation of > boost::shared_ptr<SomeClasss> > > > Greg Clayton wrote: > >> -----Original Message----- > >> From: Peter Dimov [mailto:pdimov@mmltd.net] > >> Sent: Thursday, March 11, 2004 4:48 PM > >> To: boost(a)lists.boost.org > >> Subject: Re: [boost] Explicit instantiation of > >> boost::shared_ptr<SomeClasss> > >> > >> > >> Greg Clayton wrote: > >>> I am trying to do explicitly instantiate specific shared_ptr class > >>> for export from a Win32 DLL (currently with MSVC6, and > eventually in > >>> VS2003). > >> > >> First things first. Why do you need to do that? Have you > >> tried not exporting it, have you encountered any problems? > > > > Yes, shared pointers can't be created and handed off from DLL to DLL > > the way they are currently implemented. If DLL A has an STL > container > > of shared pointers, and DLL B gets _dynamically_ loaded and adds an > > item to DLL A's container (creates a shared pointer to an > object, and > > DLL B adds that shared pointer through an interface it to > DLL A's STL > > container of shared pointers), DLL B can not be unloaded. If DLL B > > does get unloaded you will crash when your STL container goes out of > > scope (when it tries to delete the owned pointer). > > Isn't it possible for the DLL C that contains the definition > of SomeClass to > export > > shared_ptr<SomeClass> createSomeClass(); > > which DLL B can now call when it needs a SomeClass? > > Since ~SomeClass lives in C, it must be available when the last > shared_ptr<SomeClass> is destroyed. > This was my initial solution, and it does work. Though I was searching for the ability to just create a shared pointer anywhere and had it to any other DLL by exporting the entire shared pointer instantiation from the main DLL.

2 1

regex_iterator and sub_match
by Darren Cook 16 Mar '04

16 Mar '04

Hi, I finally upgrade to boost 1.31; as I got compile errors around the regex_grep stuff I decided to switch to regex_iterator. 1. It would be helpful if the top page of the docs had direct links to explanations of smatch and similar classes. 2. An example of how to use sub_match would be useful. The C++ parser example for regex_iterator is not ideal because: a) the regex is rather complex; b) the callback just uses str(), and never shows the type to use if you want to iterate through each character in the match. 3. I get this error (see P.S. for my code) `iterator' is not a member of type `boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >' but this page says sub_match has an iterator type. libs/regex/doc/sub_match.html It compiles when I explicitly use std::string::const_iterator. Darren P.S. Cut down, my code looks like: bool parse(const boost::smatch::value_type &crd,const std::string &status){ //... boost::smatch::value_type::iterator p=crd.first; // <-- won't compile //std::string::const_iterator p=crd.first; // <-- compiles while(p<crd.second){ ... } //... } //In class Functor: bool operator()(const boost::match_results<std::string::const_iterator>& m){ //... bool ok=parse(m[1],m.str(2)); //... } std::string comment; //The string to parse boost::regex status_re("..."); Functor callback(...); boost::sregex_iterator m1(comment.begin(), comment.end(), status_re); boost::sregex_iterator m2; if(m1==m2)return 0; std::for_each(m1, m2, callback);

2 1

better nondeduced context workaround?
by Larry Evans 16 Mar '04

16 Mar '04

The following file: http://groups.yahoo.com/group/boost/files/cycle_basis_mgr.hpp forms part of an adaptation of policy_ptr to collect cycles in the pointer graph. Part of the difficulty was writing specializations for a curried class, e.g. template<typename ProxVisitor> class curry_prox_visitor_refcycle_counted { public: template <typename ReferentPtr> class owner ; }; due to the restrictions on "nested contexts" (see comments under namespace rm_nondeduced ). rm_nondeduced is part of a workaround, but I was wondering if there was a better way. I'm afraid I've missed some simpler way. Any help or advice appreciated.

1 1

[Boost-bugs] [ boost-Bugs-917070 ] Bug in lexical_cast.hpp
by SourceForge.net 16 Mar '04

16 Mar '04

Bugs item #917070, was opened at 2004-03-15 21:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=917070&group_i… Category: lexical_cast Group: None Status: Open Resolution: None Priority: 5 Submitted By: John F Meinel Jr (jfmeinel) Assigned to: Kevlin Henney (kevlin) Summary: Bug in lexical_cast.hpp Initial Comment: In boost-1_31_0, I believe there is a typo in lexical_cast.hpp The line Target lexical_cast(Source arg) should be Target lexical_cast(Source& arg) Otherwise it actually creates a copy of the argument before doing the lexical cast. This causes problems if you try to lexical_cast() a virtual object. Here is code that shows the bug. By just adding the '&', the code performs as you would expect it to. #include <iostream> #include <string> #include <boost/lexical_cast.hpp> struct A { virtual int f() const = 0; }; struct B : A { virtual int f() const { return 1; } }; struct C : B { virtual int f() const { return 2; } }; std::ostream& operator<<(std::ostream& os, const A& a) { return os << a.f(); } int main() { C c; std::string s; std::cout << c << std::endl; //This should print 2 s = boost::lexical_cast<std::string>(c); std::cout << s << std::endl; //This should print 2 s = boost::lexical_cast<std::string, B>(c); std::cout << s << std::endl; //This returns 1, not 2 //This fails because it tries to instantiate an object of type A. Why??? s = boost::lexical_cast<std::string, A>(c); std::cout << s << std::endl; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=917070&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Proposal for a <stdfwd> header
by Javier Estrada 15 Mar '04

15 Mar '04

A couple of weeks ago I posted in c++ moderated: It seems natural that if there is a <iosfwd> to forward declare the I/O related classes, there should be a header for the classes contained in the std namespace. In the trenches, often times I come across classes that can be simply defined in terms of references and pointers to other classes. An example is defining interfaces or "protocol classes." Granted, with a small project, using an <stdfwd> header does not provide a big advantage, but I deal with 500+ files in a framework... I believe that the rationale is so simple that I even feel lazy about explaining the benefits, but oh well: // needlessly including the definition of string (or basic_string) and vector #include <string> #include <vector> class ISeek{ public: virtual void seek_knowledge(const std::string& token) = 0; virtual void seek_advice(const std::vector<std::string>& advisers) = 0; }; // using the proposed header... #include <stdfwd> class ISeek{ public: virtual void seek_knowledge(const std::string& token) = 0; virtual void seek_advice(const std::vector<std::string>& advisers) = 0; }; Please ready your darts and fire at will. I'd like to know if there is enough support that it could fly in a proposal to the std committee. Javier jestrada at developeer dot com

3 4

RE: [boost] Re: Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 15 Mar '04

15 Mar '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Friday, March 12, 2004 1:19 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Explicit instantiation of > boost::shared_ptr<SomeClasss> > > > "Greg Clayton" <Greg.Clayton(a)palmsource.com> writes: > > >> Greg Clayton wrote: > >> > I am trying to do explicitly instantiate specific > shared_ptr class > >> > for export from a Win32 DLL (currently with MSVC6, and eventually > > in > >> > VS2003). > >> > >> First things first. Why do you need to do that? Have you > >> tried not exporting it, have you encountered any problems? > > > > Yes, shared pointers can't be created and handed off from DLL to DLL > > the way they are currently implemented. > > I don't understand why people keep making this claim. As long as you > don't unload DLL B, you're golden. The only other alternative > prohibits unloading DLL A. I don't think that dynamically generating > a fake DLL to hold the destructors would be appropriate, so IMO > shared_ptr is as well-behaved as it can be wrt DLLs. In my case I have a main DLL that is the brains of the entire app (the model is removed from the view and controller). I also have many other DLLs that are all dynamically loaded, and that can be unloaded at any time when they are no longer needed. These extra DLLs can "register" information with this main DLL, and then go away (sometimes this info is classes that are passed across DLL boundaries using shared pointers). These extra DLLs can also ask for information from the main DLL as well. The main DLL in my case never gets unloaded until the end (actually all other DLLs link to this main DLL), but all other DLLs can be unloaded. The main issue is the virtual function table, since when you pass off ownership of the shared pointer to another DLL, the code for that vtable lives within the contributing DLL, unless you explicitly instantiate it. I have no problem with the way shared_ptr's are currently implemented, I simply want to get them working with my program, and understand what I need to watch out and plan for. > > If DLL A has an STL container of shared pointers, and DLL B gets > > _dynamically_ loaded and adds an item to DLL A's container (creates > > a shared pointer to an object, and DLL B adds that shared pointer > > through an interface it to DLL A's STL container of shared > > pointers), DLL B can not be unloaded. If DLL B does get unloaded you > > will crash when your STL container goes out of scope (when it tries > > to delete the owned pointer). The virtual function table for the > > shared pointer lives in the DLL that creates it if you just use > > something like: > > > > typedef boost::shared_ptr<SomeClass> SomeClassSP; > > > > in a header file that comes from DLL A (for other DLLs to > link to). So > > I need to instantiate and export everything for that shared pointer > > from DLL A (since it is the DLL that owns the STL containers of > > objects) so that the vtable stays valid for the lifetime of > the shared > > pointer object. > > Solution: pass the objects from B to A via std::auto_ptr. That is a great idea, I will try this. > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > >

1 0

Re: mpl rational_c and fixed_c
by Aleksey Gurtovoy 15 Mar '04

15 Mar '04

Matt Calabrese wrote: > Okay, I decided before I continue with my other library, I'll fully > implement rational_c properly (and possibly fixed_c), however, doing > so without making the code horribly complex would require changes to > the current definitions of pretty much all of the operations (plus, > multiplies, etc. as well as the conditional operators). ^^^^^^^^^^^ I suppose you meant "comparison", here and below. > > The problem is that those current functions take 5 parameters, making > specialization nearly impossible for the rational and fixed templates > as you'd have to account for when the 3rd, 4th, 5th, etc parameters > are not passed (and so the default integral 0 is used). That can't be > easily done (at least I don't see how) without having to specialize > each condition separately (one for 3 rational types, one for 4 > rational types, etc ). Moreso, this applies to the conditional > operators as well, there is no easy way to account for using different > types in multiplies IE multiplying a rational and integral together, > or a fixed and rational, etc. Again, to account for these > possibilities you'd have to make an incredibly large amount of > specializations. Of course, you could always just limit them to only > work when all the parameters are the same kind of compile-time value > template, but that would be somewhat limitting,especially with other > solutions available. I pretty much agree with the analysis. > > What I propose is a way around this situation, but still have the > metafunctions declared the same way, therefore not breaking old code > and not limiting functionality. To do so, the following adjustments > would have to be made (and I have already begun to make them for my > own use): > > 1) Additional versions of all of the arithmetic operators which take 2 > parameters, each need to be defined and work like binary operators. > They should be specialized for when both the left and right operands > are of the same type. How to account for when they are different types > will be covered in the future points. Sounds good so far. > 2) A value_cast metafunction which can cast between all different > compile-time constant types. The way it is implemented is by requiring > all types to have specialized metafunctions for converting to and from > the fixed point type. When value_cast is used, it, by default, > converts the right hand operand to fixed_c, then converts that fixed_c > to the target type. Since a fixed_c can hold pretty much any real > value to a certain precision, you can be certain, to an extent, that > little, if any precision will be lost through conversion. So, with > that proposed addition, you'd be able to convert between all different > types and only require people developing new types to have to > specialize conversion to and from fixed_c. The only problem is that in > order for the value_cast to exist, it obviously needs to have a > parameter which specifies a type to convert to. The only way I can > currently see that would allow that would be to have the value_cast > take a type parameter which would be a template instantiation with a > dummy value, which would, in a way, be very similar to rebinding > allocators. The idea of avoiding a combinatorial explosion through a single user-defined conversion metafunction which will be used to even the argument types is definitely solid; however, I am afraid we cannot escape with something as simplistic as conversion to a default predefined "contains-it-all" numeric type -- simply because there is no such type (for instance, 'fixed_c' is not capable of holding compile-time complex numbers, and so on). Moreover, specializing of arithmetic metafunctions is not necessary a prerogative of numeric types -- consider, for example, random-access iterators. To summarize, IMO the idea is excellent, but it needs to be carried a little bit further -- please see below. > 3) The conditional operations and 2 operand arithmetic operations > should be redefined in the base template definition to convert both > types to fixed_c and then make a comaprison, therefore allowing > programmers to use the operations on two different types of > compile-time constants without having to manually convert them to > similar types before-hand (as I alluded in first point). The > conditional operations can then be specialized for when the types > are the same on each side to avoid the cost of a cast on each of the > operands to fixed_c. Yep to everything except the 'fixed_c' part. > 4) The current "varying length" operations which cause problems > (multiplies, plus, minus, etc) should be redefined to just call the 2 > operand version of the corresponding operation on each of the > parameters passed to the operation. This way, programmers can still > pass multiple parameters to these functions, with each parameter being > a different type, without the developer having to make an extremely > large amount of specializations for each type (including those which > have yet to be developed). Yep! Something like template< typename N1 , typename N2 , typename N3 = int_<0> , typename N4 = int_<0> , typename N5 = int_<0> > struct plus : plus2< plus2< plus2< plus2<N1,N2>,N3 >,N4 >,N5 > { }; // ... template< typename N1 , typename N2 > struct plus<N1,N2,int_<0>,int_<0>,int_<0> > : plus2<N1,N2> { }; > > I have already begun implementing all of the points I have suggested, > though with my rational_c as a the basis for conversion rather than > fixed_c (as I haven't yet developed fixed_c). Also, converting to and > from rational_c is considerably simpler than converting to and from > fixed_c. For this reason, I may end up leaving the basis for > conversion as rational_c instead of fixed_c. > > If anyone sees any other, more elegant solutions for the problems I > mentioned, please post them and I may change my approach. Additional > suggestions are also greatly appreciated. You are going in the right direction. Here are some suggestions of how to generalize the scheme to get what I would consider an ideal solution: 1) Make specializable binary templates for each arithmetic/comparison metafunctions to be tag-dispatched metafunction classes, e.g. template< typename N1 , typename N2 > struct plus2 : plus_impl< // 'plus_impl' is a point of customization typename plus_tag<N1>::type , typename plus_tag<N2>::type >::template apply<N1,N2>::type { }; // 'plus_impl' implemenation for plain integral constants template<> struct plus_impl<integral_c_tag,integral_c_tag> { template< typename N1, typename N2 > struct apply : integral_c< BOOST_MPL_AUX_TYPEOF(N1,N1::value + N2::value) , (N1::value + N2::value) > { }; }; where 'plus_tag' is something as simple as template< typename T > struct plus_tag { typedef typename T::tag type; }; 2) Provide a rank mechanism so that we know in which direction to cast in case of mixed operations; can be as simple as an integral-constant 'rank' member of the corresponding tag: plus_tag< int_<5> >::type::rank == 0 3) Provide default implementations of '*_impl' binary templates which would use ranks, tags, and 'numeric_cast' to implement a general scheme for mixed arithmetics/comparison, something along these lines: template< bool c_ , typename Tag1 , typename Tag2 > struct plus_impl_ { template< typename N1, typename N2 > struct apply : plus_impl<Tag2,Tag2>::template apply< typename apply< numeric_cast<Tag2,Tag1>, N2>::type , N2 > { }; }; template< typename Tag1 , typename Tag2 > struct plus_impl_<false,Tag1,Tag2> { template< typename N1, typename N2 > struct apply : plus_impl<Tag1,Tag1>::template apply< N1 , typename apply< numeric_cast<Tag1,Tag2>, N2>::type > { }; }; template< typename Tag1 , typename Tag2 > struct plus_impl : plus_impl_< ( Tag1::rank < Tag2::rank ),Tag1,Tag2 > { }; Does it make any sense to you? P.S. I suggest we move the discussion to the developers list (I'm going to cross-post this one). -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[circular buffer review]
by Thorsten Ottosen 14 Mar '04

14 Mar '04

Hi All, here is my review of the circular buffer class. What is your evaluation of the design? --------------------------------------- The design is good. People can easily learn to use it. There are some miner things that I would like see changed, like double versions of push_back and push_front. I don't understand why both set_capacit and resize are provided and I would like to see them merged if possible. I also think push_back should throw an exception if no element is inserted. This behavior is somewhat different push_back() from a normal std container. If there are similar cases then I think they should be looked at again too. What is your evaluation of the implementation? ----------------------------------------------- I haven't looked closely at the source code. What is your evaluation of the documentation? ---------------------------------------------- very good once the exception-safety issues are solved What is your evaluation of the potential usefulness of the library? ---------------------------------------------------------------- I'm in doubt. The library has efficiency as its hallmark. The rationale says that it gives efficient FIFO queue. So I tried to compare it with std::deque, and here is my results of an /O2 build with vc71: $ ./cbuffer_vs_deque.exe circular_buffer<int>: 2.15 s deque<int>: 2.84 s circular_buffer<string>: 20.59 s deque<string>: 18.64 s The test program is attached; I might have made an error, but if I have not, then I don't see the claim as true. In that case I need to see some more evidence about why the speed advantages should be so good. It also make me wonder if there is any need for circular_buffer_space_optimized. Did you try to use the library? With what compiler? Did you have any problems? ---------------------------------------------------------------------------- ------ yes, with vc7.1; Comeau 4.3.0 could not compile it. It worked fine on vc7.1 How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ---------------------------------------------------------------------------- ------------------- A couple of hours with both documentation and code use. Are you knowledgeable about the problem domain? ----------------------------------------------------- I don't have experience with embedded applications; I have written stuff in which performace was critical and in which specially designed datastructures was necessary. Do you think the library should be accepted as a Boost library? --------------------------------------------------------------- Yes if the author can convince me that we really get more performance. No otherwise. best regards Thorsten begin 666 cbuffer_vs_deque.cpp M(V1E9FEN92!"3T]35%]$25-!0DQ%7T-"7T1%0E5'(#$-"@T*(VEN8VQU9&4@ M(F)O;W-T+V-I<F-U;&%R7V)U9F9E<BYH<' B#0HC:6YC;'5D92 \8F]O<W0O M<')O9W)E<W,N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+W1H<F5A9"]T:')E860N M:'!P/@T*(VEN8VQU9&4@/&1E<75E/@T*(VEN8VQU9&4@/'-T<FEN9SX-"B-I M;F-L=61E(#QI;W-T<F5A;3X-"@T*=7-I;F<@;F%M97-P86-E(&)O;W-T.PT* M=7-I;F<@;F%M97-P86-E('-T9#L-"@T*;75T97@@<75E=65?;75T97@[#0IC M;VYS="!I;G0@<75E=65?<VEZ92 @(" @/2 U,# [#0IC;VYS="!I;G0@=&]T M86Q?96QE;65N=',@/2!Q=65U95]S:7IE("H@,3 P,# P.PT*#0IT96UP;&%T M93P@='EP96YA;64@475E=64@/@T*:6YL:6YE(&)O;VP@:7-?9G5L;"@@8V]N M<W0@475E=64F(&,@*0T*>PT*(" @(')E='5R;B!C+G-I>F4H*2 ]/2!Q=65U M95]S:7IE.PT*?0T*#0IT96UP;&%T93P@='EP96YA;64@475E=64@/@T*8VQA M<W,@<F5A9&5R#0I[#0H@(" @='EP961E9B!T>7!E;F%M92!1=65U93HZ=F%L M=65?='EP92!4.PT*(" @(%%U975E)B @<3L-"B @(" -"G!U8FQI8SH-"B @ M("!R96%D97(H(%%U975E)B!Q("D@.B!Q*'$I('L@?0T*(" @( T*(" @('9O M:60@;W!E<F%T;W(H*2@I#0H@(" @>PT*(" @(" @("!I;G0@<F5A9%]E;&5M M96YT<R ](# [#0H@(" @(" @( T*(" @(" @("!W:&EL92@@<F5A9%]E;&5M M96YT<R \('1O=&%L7V5L96UE;G1S("D@(" -"B @(" @(" @>PT*(" @(" @ M(" @(" @:68H("%Q+F5M<'1Y*"D@*2 @( T*(" @(" @(" @(" @>PT*(" @ M(" @(" @(" @(" @('L-"B @(" @(" @(" @(" @(" @(" @;75T97@Z.G-C M;W!E9%]L;V-K(&QO8VLH(&UU=&5X("D[#0H@(" @(" @(" @(" @(" @(" @ M(%0@=" ]('$N8F%C:R@I.PT*(" @(" @(" @(" @(" @(" @("!Q+G!O<%]B M86-K*"D[#0H@(" @(" @(" @(" @(" @?0T*(" @(" @(" @(" @(" @("LK M<F5A9%]E;&5M96YT<SL-"B @(" @(" @(" @('T-"B @(" @(" @(" @(&5L M<V4-"B @(" @(" @(" @(" @("!R96%D7W1H<F5A9"@I+3YY:65L9"@I.PT* M(" @(" @("!]#0H@(" @?0T*(" @( T*(" @('-T871I8R!T:')E860J)B!R M96%D7W1H<F5A9"@I#0H@(" @>PT*(" @(" @("!S=&%T:6,@=&AR96%D*B!T M(#T@,#L-"B @(" @(" @<F5T=7)N('0[#0H@(" @?0T*?3L-"@T*=&5M<&QA M=&4\('1Y<&5N86UE(%%U975E(#X-"F-L87-S('=R:71E<@T*>PT*(" @('1Y M<&5D968@='EP96YA;64(a)475E=64Z.G9A;'5E7W1Y<&4@5#L-"B @("!1=65U M928@('$[#0H@(" @#0IP=6)L:6,Z#0H@(" @=W)I=&5R*"!1=65U928@<2 I M(#H@<2AQ*2![('T-"B @(" -"B @("!V;VED(&]P97)A=&]R*"DH*0T*(" @ M('L-"B @(" @(" @:6YT('=R:71T96Y?96QE;65N=',@/2 P.PT*(" @(" @ M("!W:&EL92@@=W)I='1E;E]E;&5M96YT<R \('1O=&%L7V5L96UE;G1S("D- M"B @(" @(" @>PT*(" @(" @(" @(" @:68H("%I<U]F=6QL*"!Q("D@*0T* M(" @(" @(" @(" @>PT*(" @(" @(" @(" @(" @('L-"B @(" @(" @(" @ M(" @(" @(" @;75T97@Z.G-C;W!E9%]L;V-K(&QO8VLH(&UU=&5X("D[#0H@ M(" @(" @(" @(" @(" @(" @('$N<'5S:%]B86-K*"!4*"D@*3L-"B @(" @ M(" @(" @(" @("!]#0H@(" @(" @(" @(" @(" @*RMW<FET=&5N7V5L96UE M;G1S.PT*(" @(" @(" @(" @?0T*(" @(" @(" @(" @96QS92 @(" -"B @ M(" @(" @(" @(" @("!W<FET95]T:')E860H*2T^>6EE;&0H*3L-"B @(" @ M(" @?0T*(" @('T-"B @(" @(" @#0H@(" @<W1A=&EC('1H<F5A9"HF('=R M:71E7W1H<F5A9"@I#0H@(" @>PT*(" @(" @("!S=&%T:6,@=&AR96%D*B!T M(#T@,#L-"B @(" @(" @<F5T=7)N('0[#0H@(" @?0T*?3L-"@T*#0IT96UP M;&%T93P@='EP96YA;64@475E=64@/@T*=F]I9"!F:69O7W1E<W0H*0T*>PT* M(" @('!R;V=R97-S7W1I;65R('0[#0H@(" @475E=64@('$H('%U975E7W-I M>F4@*3L-"B @("!R96%D97(\475E=64^(')E861E<B@@<2 I.PT*(" @('=R M:71E<CQ1=65U93X@=W)I=&5R*"!Q("D[(" @( T*(" @('1H<F5A9"!R96%D M*"!R96%D97(@*3L-"B @("!T:')E860@=W)I=&4H('=R:71E<B I.PT*(" @ M(')E861E<BYR96%D7W1H<F5A9"@I(#T@)G)E860[#0H@(" @=W)I=&5R+G=R M:71E7W1H<F5A9"@I(#T@)G=R:71E.PT*(" @(" @(" -"B @("!R96%D+FIO M:6XH*3L-"B @("!W<FET92YJ;VEN*"D[(" @(" @(" @(" -"@T*?0T*#0II M;G0@;6%I;B@I#0I[#0H@(" @8V]U=" \/" B7&X@8VER8W5L87)?8G5F9F5R M/&EN=#XZ("([#0H@(" @9FEF;U]T97-T/"!C:7)C=6QA<E]B=69F97(\:6YT M/B ^*"D[#0H@(" @#0H@(" @8V]U=" \/" B7&X@9&5Q=64\:6YT/CH@(CL- M"B @("!F:69O7W1E<W0\(&1E<75E/&EN=#X@/B@I.PT*#0H@(" @8V]U=" \ M/" B7&X@8VER8W5L87)?8G5F9F5R/'-T<FEN9SXZ("([#0H@(" @9FEF;U]T M97-T/"!C:7)C=6QA<E]B=69F97(\<W1R:6YG/B ^*"D[#0H@(" @#0H@(" @ M8V]U=" \/" B7&X@9&5Q=64\<W1R:6YG/CH@(CL-"B @("!F:69O7W1E<W0\ K(&1E<75E/'-T<FEN9SX@/B@I.PT*#0H@(" @<F5T=7)N(# [#0I]#0H-"@`` ` end

4 9

Sandbox CVS warning
by Gennaro Prota 14 Mar '04

14 Mar '04

I keep getting the following warning when committing files to the sandbox CVS: warning: cannot write to history file /cvsroot/CVSROOT/history: Permission denied Is all ok or should I be worried? Thanks in advance, Genny.

1 0

Implicitly-Callable Functions in C++0x?
by Beman Dawes 14 Mar '04

14 Mar '04

There's a proposal (N1611) "Implicitly-Callable Functions in C++0x" by Walter Brown in the C++ committee's pre-meeting papers. See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf Given all the Boost work that has gone into math constants, function issues, and to a lesser extent, properties, I'd guess several Boosters might want to comment on Walter's proposal. Strong support from library developers like Boost participants would almost be a requirement for such a proposal to be accepted, IMO. But do remember that only so many proposals can be accepted, and that every proposal that gets accepted pushes some other proposal aside. comp.std.c++ is the best place to post comments, since it is probably read by more of the committee's Evolution Working Group than read the Boost list. See http://groups.google.com/groups?q=comp.std.c%2B%2B for a web interface. A comment on comp.std.c++ should probably be like Boost review; say in plain language if you support or oppose the proposal so detailed comments don't obscure an overall view. (The Boost list is read by many active C++ committee members, but they tend to be library oriented rather than core language or evolution oriented.) An extended discussion of such a proposal would probably stray off-topic for Boost anyhow. --Beman PS: if you are interested in other proposals for the next C++ standard, http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/#pre_sydney has a wealth of interesting papers.

10 12

Re:[boost] Re: Re:Re: serialization library #17
by Robert Ramey 13 Mar '04

13 Mar '04

Jeff Flinn wrote: >Any thoughts on future serialization of boost::function even being >possible? >My use case is that I've a std::map of std::string/boost::function's that >provide user configurable filters that detemine what gets displayed in a >Table/List View. These currently are not being saved between sessions. It'd >be great to do mFilterMap & ar; Why would this not be possible, I don't see reason why it would be any kind of special case? Robert Ramey

1 0

Re:Re: Re:Re: [boost] [compatibility headers] fixes for Borland
by Robert Ramey 13 Mar '04

13 Mar '04

John Maddock wrote: >> Robert Ramey wrote: >> a) Sprinkle #ifdef BORLAND in those 14 files >> b) Tweak cpp_c_headers files >> c) Or ? what? >> >> What is the least worst way to handle this? >> >> If I have to use a) what is the point of even having cpp_c_headers? >Here's the problem: those headers were only supplied as a workaround for >compilers that don't supply new style headers at all, they all use the >following workaround: >#include <string.h> >namespace std{ using ::memcpy; } //etc >However for conforming compilers this is defective for two reasons: >It needlessly introduces C functions into the global namespace (including ><cstring> should not do that). >It shouldn't compile at all: memcpy is already declared in std, the version >in the global namespace is an alias introduced with a using declaration,and >importing it back into std *should fail*. >Now the interesting thing is, I know of only two vendors who are shipping >std conforming C headers: Borland and Metrowerks. Since you don't mention >the latter my guess is you're not testing with it ;-) >The normal workaround that Boost libs have been using is: >#include <cstring> >#include <boost/config.hpp> >#ifdef BOOST_NO_STDC_NAMESPACE >namespace std{ using ::memcpy; } >#endif OK, I can live with this. But if cpp_c_headers has conditioned on the compiler then what is the point of having it all? What use can it have? Robert Ramey

2 1

filesystem doc nit
by David Abrahams 13 Mar '04

13 Mar '04

"The Filesystem Library's fstream.hpp header simply uses the <fstream> standard library components as base classes, and then overrides the members requiring argument types of path." Technically, I don't think this is overriding, and the base classes don't require path arguments. Maybe you mean: "The Filesystem Library's fstream.hpp header simply uses the <fstream> standard library components as base classes, and then adds constructors, and overloads of the base interfaces, that accept path arguments instead of strings" -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Formal Review: Circular Buffer
by Pavel Vozenilek 12 Mar '04

12 Mar '04

The review of Jan Gaspar's Circular Buffer library starts today (March 5th) and runs for 10 days. Latest version of the library is available at: http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip What it is: Circular buffer (also known as ring or cyclic buffer) is container with fixed upper limit on number of elements inside. When capacity gets exhausted newly inserted elements will cause oldest elements to get dropped out. What makes the library Boost candidate: - it provides often used functionality, - it is STL compliant generic solution, - it is designed for CPU/memory efficiency, - it is fully documented and tested, - it contains extensive debug support, - it has been informally reviewed for long time. Discovered problems in code or in documentation, missing features, portability issues and finally opinion whether the library belongs to Boost is welcomed. /Pavel

13 59

filesystem hard link question
by Neal D. Becker 12 Mar '04

12 Mar '04

I am using the following common idiom: link (name, name.old) rename (name.new, name) To update a file atomically I'm interested in using boost::filesystem instead of libc, but I didn't find any equivalent of link in filesystem. Did I miss it? Should it be added?

6 15

Re: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
by Peter Dimov 12 Mar '04

12 Mar '04

(resend) > Greg Clayton wrote: >> >> Yes, shared pointers can't be created and handed off from DLL to DLL >> the way they are currently implemented. If DLL A has an STL container >> of shared pointers, and DLL B gets _dynamically_ loaded and adds an >> item to DLL A's container (creates a shared pointer to an object, and >> DLL B adds that shared pointer through an interface it to DLL A's STL >> container of shared pointers), DLL B can not be unloaded. If DLL B >> does get unloaded you will crash when your STL container goes out of >> scope (when it tries to delete the owned pointer). > > Isn't it possible for the DLL C that contains the definition of > SomeClass to export > > shared_ptr<SomeClass> createSomeClass(); > > which DLL B can now call when it needs a SomeClass? > > Since ~SomeClass lives in C, it must be available when the last > shared_ptr<SomeClass> is destroyed.

1 0

Numeric Conversion Library?
by David Abrahams 12 Mar '04

12 Mar '04

http://article.gmane.org/gmane.comp.lib.boost.announce/37 It was accepted, right? When will it be added to CVS? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

RE: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 12 Mar '04

12 Mar '04

> -----Original Message----- > From: Peter Dimov [mailto:pdimov@mmltd.net] > Sent: Thursday, March 11, 2004 4:48 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Explicit instantiation of > boost::shared_ptr<SomeClasss> > > > Greg Clayton wrote: > > I am trying to do explicitly instantiate specific shared_ptr class > > for export from a Win32 DLL (currently with MSVC6, and eventually in > > VS2003). > > First things first. Why do you need to do that? Have you > tried not exporting it, have you encountered any problems? Yes, shared pointers can't be created and handed off from DLL to DLL the way they are currently implemented. If DLL A has an STL container of shared pointers, and DLL B gets _dynamically_ loaded and adds an item to DLL A's container (creates a shared pointer to an object, and DLL B adds that shared pointer through an interface it to DLL A's STL container of shared pointers), DLL B can not be unloaded. If DLL B does get unloaded you will crash when your STL container goes out of scope (when it tries to delete the owned pointer). The virtual function table for the shared pointer lives in the DLL that creates it if you just use something like: typedef boost::shared_ptr<SomeClass> SomeClassSP; in a header file that comes from DLL A (for other DLLs to link to). So I need to instantiate and export everything for that shared pointer from DLL A (since it is the DLL that owns the STL containers of objects) so that the vtable stays valid for the lifetime of the shared pointer object. > [...] > > > When I look through the exports, some needed class functions seem to > > be missing from the DLL, and linking fails. Most notable are: > > > > void boost::shared_ptr<SomeClass>::reset(SomeClass*) > > > > This function is declared in the shared_ptr header file as: > > template<class Y> void reset(Y * p); > > This is a function template. A template can't be exported, only an > instantiation. > > template void boost::shared_ptr<SomeClass>::reset(SomeClass*); > > should instantiate reset with Y=SomeClass. After I sent the original email to this list I tried something similar, but it didn't seem to work (didn't see it in my export list). I will try it with VS2003 and see if I have better luck.

3 2

Re:[boost] [serialization] serializable objects implemented in
by Robert Ramey 12 Mar '04

12 Mar '04

David Tonge wrote: > Anyway, I've resolved that by making a more complicated macro for > exporting the guids, which doesn't use any typedefs. Although the shared_ptr serialization does work in the demos and tests, I've conceded that its probably going to need another pass to address such situations such as mult-threading, exception safety, polymorphic pointers and now perhaps instanciation issues. I think this will require access to the class header which I don't have (or want). I think for now it's OK to handle situations on an ad-hoc basis as you have done. In the long run I hope someone gets around to making the shared_ptr serialization complete and bullet-proof. > I think that part of the problem was that my solution for exporting the > guids for shared_ptrs was like this... >typedef boost::detail::sp_counted_base_impl<T*, ....> T_shared_ptr; >BOOST_CLASS_EXPORT(T_shared_ptr); In general, the macros don't really handle template arguments. Maybe they should. (Is there a pre-processor macro IS_TEMPLATE(x) ? ) > Now to my other problem. I wanted to investigate the serialization > tools in the context of a larger project. My habit is to define my > class interfaces in header files, like base_class.h, and provide their > implementations in source files like base_class.cpp. I like my headers > to be lightweight and include the minimum number of other header files > in order that compilation times don't get out of hand. > I had been including the BOOST_CLASS_EXPORT(T) commands in the headers > but that means I have to include all of the archive headers, and > export.hpp in every header, and that makes for slow compilations. My > hope is that I can include all of those only in the implementation .cpp > and put the BOOST_CLASS_EXPORT(T) there. I was also worried that if I > included the BOOST_CLASS_EXPORT(T) in the header then every other .cpp > which included that header would also try to register the guid for T - > surely an unnecessary replication of effort. Having done all of this I found that my program would work fine if everything existed in a single EXE. However, if I implement them as a DLL containing my base_class and derived_class implementations and an EXE, which uses these classes, then things fail. The export/registration mechanism is used to relate a key/class_id stored in the archive with the appropriate de-serialization function. With the case of polymorphic pointers, the issue of instantiation of de-serialization code also has to be addressed. As things get more ambitious, the situation has to be explicitly considerd. I think the key example here is demo_pimpl. I couldn't get this to link properly with VC 6.0 and VC 7.0. With gcc it always worked. With VC 7.1 it started to work for Microsoft compilers. To make it work I had to explicitly instantiate the templates used for exported classes. I believe that you're situation will also require a little extra help - I'm not sure yet, but I'll look into it. I've stepped through the code for exe_using_dll and I can see that the failure occurs when it tries to get extended type information for the derived_class (at line 297 of oserializer.hpp). However, I know that the class has been registered by the guid_initializer (at line 130 of export.hpp) because I put a breakpoint there, and saw initialization happen for base_class, derived_class and the shared_ptr versions of both. > My suspicion is that the problem is caused by the serialization library > using a static library, rather than a DLL. If the BOOST_CLASS_EXPORT > commands updated a list contained in the static library then there would > be one instance of this list statically linked into my DLL, and another > in my EXE. Thus, the registration occurring in the DLL wouldn't affect > the list used in the EXE. As Vladimir pointed out (I think) , a DLL version of the library is easily generated by a simple enhancement to the jamfile in the build directory. I haven't done this nor have I tested it. I see no reason why it shouldn't work without problem. (hmm - I don't know if this automatically generates an export lib). Adding auto_lib functionality to the serialization library would cleanly handle all issues related to build and usage of DLL versions. I've not done so as I think it's premature given that the library has not been accepted into boost. I suspect your suspicion is more or less on the right track. The library uses a little bit of trickery to be sure that extended_type_info information is generated and stored in a global table for each exported class at pre-compile time. When called from a DLL, most likely it's a separate table in the DLL so it wouldn't be found when doing the lookup from the main exe. I suspect this is addressable though I haven't yet considered it. > If this is the case then it's going to be quite inconvenient. It would > mean one would have to BOOST_CLASS_EXPORT every class in every DLL where > an instance of it (or a shared_pointer which might contain it) might be > saved. If that were the case then I'd advocate making > boost_serialization into a DLL, rather than a static library. > It would mean one would have to BOOST_CLASS_EXPORT every class in every > DLL where an instance of it (or a shared_pointer which might contain it) > might be saved. I think a better solution would be to build you implementation classes as static libraries. (see the demo_pimpl). This addresses the issue of long compile times nicely. I believe will get you what you want. You won't have a separate DLL which may or may not be an issue depending upon your taste and situation. Also, I believe that the DLL situation will probably work now if ALL the code that invokes serialization for a particular class is found in the same DLL. An interesting experiment would be to see what would happen if the demo_pimpl is reformlated to use a (1) static library and (2) a DLL. In the longer run we'll look at this more carefully. Its conceivable that just the extended_type_instantion might be in a static lib while the rest is in a DLL or maybe the export process can be tweaked to be sure that DLLS, use the same table. At this point I really can't say. Another option (also mentioned by Vladimir and also in the documentation) is the creation of a "virtual_archive" interface. This is similar to the way the package that was reviewed over a year ago handled the issue. I have looked into this a little and have concluded that it will be quite easy to implement - though I've deferred it for now. > If that were the case then I'd advocate making > boost_serialization into a DLL, rather than a static library. I don't think that would help > I'd be grateful if you could take a look at my example, and let me know > if there is something I can do to resolve my problems. I'll look at it. Robert Ramey

1 0

Re:Re: [boost] [compatibility headers] fixes for Borland
by Robert Ramey 12 Mar '04

12 Mar '04

John Maddock wrote: >> Compatibility headers (in boost\compatibility\cpp_c_headers) >> don't compile with BCB 6.4. >I'm confused why you would be using those - Borland supplies the new style >headers with everything in namespace std already doesn't it? Here's our problem, In the serialization library there are 14 files that use functions from the std namespace. In order to compile these under VC 6.0 ( and perhaps other platforms ) we specify: #include <boost/compatibility/cpp_c_headers/cstring> // memcpy This resolves the issue with vc 6.0 ( and who knows who else ? maybe STLPort ? ). Conformant compilers don't seem to be affected adversely by this. The code itself uses a standard "std::memcpy" and everything is pretty clean. Now comes along Borland - the files ccp_c_headers won't compiler here. So now we're in a quandary. a) Sprinkle #ifdef BORLAND in those 14 files b) Tweak cpp_c_headers files c) Or ? what? What is the least worst way to handle this? If I have to use a) what is the point of even having cpp_c_headers? Robert Ramey

3 2