RE: [boost] Relational tables: Ditto and RTL
> -Original Message- > From: Arkadiy Vertleyb [mailto:vertleyb@;hotmail.com] > > > - RTL does not seem to automatically update it's views (or > whatever it is > > known as in RTL terminology); when a record is added to a > table (or view), > > it is not immediately available in all other views based on > that table. > > This is true, although we did have an idea to address this in > the future. I > have to admit, at this point this is only an idea. I'm not entirely clear on what this means in practice. If I instantiate an operator using a table then add or delete elements from the table, I have violated the concept that all relations are constant objects. However, according to the (very good) docs all (?) that instantiating an operator does is to store references to its parameters (the tables). It is only when I obtain and dereference (?) a relation iterator (using print, or calling begin() then dereferencing) that iteration over the tables occurs. If I have tables which are not in fact const must I: a) Modify the tables and create new relation iterators OR b) Modify the tables and create new relation operators as well as iterators OR c) Create the tables, operators and iterators from scratch whenever a table changes How concrete is the idea? As a potential user of some form of in-memory database that definitely needs relations/views based on multiple tables and that will have insertions and deletions (not necessarily vast numbers of them) I'm very interested in this. Regards Darryl Green. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] DocBook/XML Reference Documentation updates
Hello all, I've improved the DocBook-based reference documentation a bit more. Changes & new features: - Ability to use the Docbookesque foo to create a link to the class named "foo" (as defined in a reference section) within text, function signatures, etc. - Better support for syntax highlighting - Better support for man pages The current HTMLized version of the Boost.Function docs (incomplete, but getting closer...) is here: http://www.cs.rpi.edu/~gregod/Boost/function-html/ The man pages (very much improved!) are available here: http://www.cs.rpi.edu/~gregod/Boost/function-man/ Is this the way we want to go with documentation? Should we explore other options (e.g., LaTeX) further, or is there any other part of the system we need to see working before we can choose? We need a better documentation solution for Boost, but if developers think we are going the wrong way and won't use it (and don't speak up), then the situation is dire indeed. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Relational tables: Ditto and RTL
Hi, I have to admit that I missed this interesting discussion -- shame on me! We still have to learn more about Ditto to form our view on how the libraries should relate to each other. For now, I would like to clarify some places in RTL that were subject of this discussion: > - RTL uses expressions for sorting/filtering whereas Ditto uses functors. Sorting in RTL is done by indexing. For example, if there is a relation t sorted on c1, then "iterator_index >(t)" is the same relation sorted on c2. The name "iterator_index" reflects the fact that internally iterators are used. The "relation" stands for either a table or an operator. Filtering in RTL is implemented as "selection" operator, which accepts a functor. There are a few pre-defined functors, which can be combined in expressions. > - RTL does not seem to automatically update it's views (or whatever it is > known as in RTL terminology); when a record is added to a table (or view), > it is not immediately available in all other views based on that table. This is true, although we did have an idea to address this in the future. I have to admit, at this point this is only an idea. > - Ditto can stack views as to provide multiple levels of refinement of the > underlying table. So can RTL: iterator_index >(selection_eq(iterator_index >(t), tuple >(5))); would sort "t" on c2, find all tuples where c2 = 5, and re-sort it back on c1. Any other combination of relational operators is also possible. > - RTL can mix multiple tables into one singular view, Ditto currently cannot > (though the architecture is capable of this). Right. > - Ditto can assign events (using callback functors) whenever a record is > added/changed/deleted and even when other events are triggered. We can't do this now. Again there is an idea to address this in the future. > - Ditto can keep a pointer to a single record by means of a tracker class > which also plugs into the event mechanism, I don't know if/how RTL handles > this. We have iterators. > RTL seems to want to be an in-memory relational database. Almost true. RTL is intended to be a "relational algebra library". We want to decouple relational algebra from the table implementation, so that both in-memory and disk-base implementations are possible and can be used together. For now we have only in-memory table implementation. It may or may not turn out that only in-memory implementations make sence in this context. The idea is, adding new table implementations should be transparent to the library. If our solution turnes out to be attractive enough, some people who know more about data structures than we do, might want to write better table implementations than one based on sorted vector, that we currently have. Any such suggestions would be most welcome. As I said, we need to look in Ditto more closely to form our view on how the libraries should relate to each other. Regards, Arkadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [uBLAS] Interest in Possible Small RefactorisationContribution
Hi Guys, So far I am very happy with uBLAS. Thanks. I noticed some minor duplication in vector.hpp so using cut & paste and a little inventiveness I have refactored scalar_vector, unit_vector and zero_vector into a single function_vector that takes a single vector_index_functor as its template argument. The benefits of this refactorisation is that users can further extend with instances of analytical functions / interpolants / whatever into a vector and it will use the uBLAS optimisations and constructs as appropriate. I have already been using it and *really* find it useful where I don't want to use excessive memory or less efficient constructs when calculating difference norms and/or resolving discretisations. It also saves a reasonable amount of duplication in vector.hpp. Furthermore, I suspect that it might not be an order of complexity further to create a function_matrix too based on the same ideas and for the same benefits. Is anyone interested in my work on this? I am guessing that the original maintainers probably have already thought of this as a lot of their work is still over my head. If anyone is interested and would like to guide and review my efforts (needed as this would potentially be my first open source contribution -- although small) I am happy to do more. I am hoping that (as it is mostly a cut&paste and as my original work closely copies the style of the rest of uBLAS) it would be easy to assimilate quickly. Matt http://careers.yahoo.com.au - Yahoo! Careers - 1,000's of jobs waiting online for you! ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::graph - incorrect answers withdikjstra_shorts_paths
Hi Marc, I don't have time to look at this right now, but I'll try to get to it this weekend. Regards, Jeremy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Property_map docs
On Thursday 14 November 2002 01:23 pm, Edward Diener wrote: > "all these concepts are for you the implementor to put together to > create the generic functions that work using the categories mentioned. > There is no implementation here." I am not a native speaker but doesn't "concept" imply something that is abstract? If so, wouldn't that make the above explanation redundant? -- Alkis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed bit_struct submission to Boost
"Kevin S. Van Horn" <[EMAIL PROTECTED]> writes: > David Abrahams writes: > >> Looks cool. I don't usually need such a thing, though. Could you give >> some examples of likely use cases? > > The impetus for bit_struct was a discussion with a local business on possible > student library projects that would benefit the business. This company writes > a lot of embedded software. They are dealing with a network protocol that > allows them to pack any number of parameters into a message of exactly eight ^^ Really?! > bytes. Note that byte order within multibyte integers is an issue I > have not addressed with bitstruct; if one wishes to send a bitstruct > over the network, then either the sender and receiver must have the > same integer sizes and byte orders, or you need an additional > facility to put bytes into a standard order (like the Unix htonl, > htons, ntohl, and ntohs functions, but templatized.) > > This kind of thing might also be useful in writing memory > allocators, where you want to tightly pack information into a small > header for a block of memory. It might also be useful in > implementing tagged data for dynamically-typed languages. Thanks for the explanation. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Property_map docs
One more suggestion which you can follow or not: Show the code for at least one complete implementation of property map, no matter how practically non-useful or simple it may be, based on your concepts in a clear manner. Then someone trying to understand your concept will understand what practical use your idea may have for their own implementations. Thanks ! "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message news:2147483647.1037292139@;[10.56.73.193]... > Hi Edward, > > What you say below is an excellent suggestion, and I'll add that > to the introduction in the docs for property map. > > Best Regards, > Jeremy > > --On Thursday, November 14, 2002 4:23 PM -0500 Edward Diener > <[EMAIL PROTECTED]> wrote: > > > I would still say to anyone willing to listen that the doc should spell > > this out, ie. "all these concepts are for you the implementor to put > > together to create the generic functions that work using the categories > > mentioned. There is no implementation here." If I had read that I might > > still have been interested in the concepts as pure ideas, but I would > > have probably moved on pretty quickly, or further looked into the BGL to > > see what was a practical implementation of this concept, but I would not > > have posted anything here regarding the doc which I clearly didn't > > understand and couldn't make heads or tails out of. It was my frustration > > about reading the pieces of what I though was an implementation, and not > > having any idea how these pieces were supposed to fit together to form > > some sort of reality, that led to my frustration and initial post. > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization Submission version 6
"William E. Kempf" <[EMAIL PROTECTED]> writes: > David Abrahams said: >> "Eric Woodruff" <[EMAIL PROTECTED]> writes: >> >>> type_info is not portable in the slightest. >> >> There are lots of applications where that doesn't matter. And with a >> little postprocessing, the type_info::name() produced by most >> compilers could easily be normalized into a common format. > > The trouble is that serialization requires an identifier that's > persistant across application runs. Not all uses of serialization depend on that. > type_info by itself doesn't help here, because you can't persist the > type_info instance even if it were gauranteed to compare across runs > (obviously it's not). type_info::name() is so underspecified that > you can't be sure it won't give you the same string for every type. > More importantly, in practice (i.e. implementations do this), > type_info::name() will often give you strings that are *not* unique, > rendering it worthless for this domain. Which implementations? Boost.Python v2 /depends/ on type_info::name() returning a usefully-unique string on many platforms (depending on their dynamic linking model). I've never seen an example of a platform which "often give you strings that are *not* unique", but if they're out there, I need to know about them. > Can type_info::name() be useful? Yes, provided the implementation did > something useful, but it's not portable, and not useful for the task at > hand. There are lots of tasks you can do with a serialization library, and I submit that a reasonable proportion of those tasks can take advantage of type_info::name() on a useful number of compilers. > BTW, there's a LOT to be said for specifically supplying an > identifier when implementing a persistence/serialization library, > even though it means tedious busy work. Specifically, it allows you > to insure the id is valid across multiple programs, regardless of > how the implementation might auto-magically generate an identifier. > I'd recommend choosing a "large integer" representation instead of a > string, however, since it will take less space to represent > externally. The GUID type is actually a fairly good choice here. Maybe it would make sense to use Steve Dewhurst's typeof() technique. At least that could help reduce the number of user-supplied identifiers needed. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL lambda
Hi, Alexey. I am having hard time grasping how this %#$% lambda facility is working. Unfortunally paper does not provide enough information. Could you at least provide general scetch?Amoung other things I would like to know when I need to use _ and when _1,_2,...? Could you write in a form of step by step description how fold-family algorithms are working? Also is there gen_scattered/linear_hierarchy implementation somewhere for MPL sequenses? Thank you, Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, November 14, 2002 7:18 PM
Subject: Re: [boost] Proposed Boost Assert -- once again
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > - Original Message -
> > From: "Peter Dimov" <[EMAIL PROTECTED]>
> > To: "Boost mailing list" <[EMAIL PROTECTED]>
> > Sent: Thursday, November 14, 2002 1:32 PM
> > Subject: Re: [boost] Proposed Boost Assert -- once again
> >
> >
> >> - there is no explicit support for throwing exceptions, and no standard
> >> exception class is defined. (Although it is trivial to define a handler
> > that
> >> throws.) This is intentional. I don't believe that we, at Boost, want
to
> >> encourage this particular programming practice (assertions that throw.)
> >>
> > AFAIK, the differences between abort and throw are two-fold.
> >
> > On one hand, there are platform/compiler-dependent differences.
> > Some enviroments (mostly Unix-like) don't allow you to get context
> > information at the point of the throw, but, OTOH, supply a core-dump in
the
> > case of abort(). On these enviroments, abort() is clearly superior.
> > Other enviroments (Windows) do allow you to get context information at
the
> > point of the throw and do not supply a *textual* core-dump for
post-morten
> > debugging (although you can use JIT). On this enviroment, throw is
clearly
> > superior.
>
> Strong disagreement! Regular exception handling constructs can
> interfere with your ability to do post-mortem debugging if you assert
> by throwing an exception.
OK. I accept that exceptions are only viable IIF the debugger can stop right
after it is thrown; unless you need to application to keep running which is
really an application-level problem, not library-level.
>That makes asm { int 3 } or the equivalent
> (which is what most of the built-in asserts do) much better on Windows
> for assertions. Regular exception-handling constructs can also
> interfere with asm{int 3}, but fortunately it's fairly easy to prevent
> that in most cases. See libs/python/test/module_tail.cpp for the
> trick.
>
Oh yes, the good old DebugBreak() which is available in the Windows API. I
forgot about it.
All right, Borland's assert calls abort() unfortunately, which makes it
pretty useless; but the DebugBreak() trick is really good! I like it.
So I would settle for this 'trap into debugger' trick for assertion
behavior. No exceptions.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Sent: Thursday, November 14, 2002 1:32 PM
> Subject: Re: [boost] Proposed Boost Assert -- once again
>
>
>> - there is no explicit support for throwing exceptions, and no standard
>> exception class is defined. (Although it is trivial to define a handler
> that
>> throws.) This is intentional. I don't believe that we, at Boost, want to
>> encourage this particular programming practice (assertions that throw.)
>>
> AFAIK, the differences between abort and throw are two-fold.
>
> On one hand, there are platform/compiler-dependent differences.
> Some enviroments (mostly Unix-like) don't allow you to get context
> information at the point of the throw, but, OTOH, supply a core-dump in the
> case of abort(). On these enviroments, abort() is clearly superior.
> Other enviroments (Windows) do allow you to get context information at the
> point of the throw and do not supply a *textual* core-dump for post-morten
> debugging (although you can use JIT). On this enviroment, throw is clearly
> superior.
Strong disagreement! Regular exception handling constructs can
interfere with your ability to do post-mortem debugging if you assert
by throwing an exception. That makes asm { int 3 } or the equivalent
(which is what most of the built-in asserts do) much better on Windows
for assertions. Regular exception-handling constructs can also
interfere with asm{int 3}, but fortunately it's fairly easy to prevent
that in most cases. See libs/python/test/module_tail.cpp for the
trick.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
Peter Dimov writes: > what is the intended audience of BOOST_ASSERT, Boost library developers > or "end users"? Both. I would like a uniform way of handling assertions / tests of preconditions in Boost libraries, and I would also like to be able to use it in application code. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
Peter Dimov writes: > The new boost/assert.hpp is now in CVS, I'll copy it below for > convenience: It's simplicity is certainly an advantage. > The main difference between this version and the old assert.hpp is that > BOOST_ASSERT now uses the standard assert by default, Hmmm... I guess my previous objection to doing this by default doesn't really hold here, because if NDEBUG is defined the assert() is a no-op. However, a couple of quibbles: 1. The proper C++ header file is , not . 2. I think using familiar terminology is preferable. Developers already know what NDEBUG does and how to use it, so I would prefer that BOOST_DISABLE_ASSERTS be renamed BOOST_NDEBUG. > I've introduced separate BOOST_DISABLE_ASSERTS and > BOOST_ENABLE_ASSERT_HANDLER macros since relying > on the BOOST_DEBUG "magic values" to control behavior seemed inferior. I agree. Nobody wants to try to remember such numeric codes. > assertion_failed is declared but left undefined, the user is expected to > supply a definition. Compared to a set_assert_handler approach, this has > the advantage that the handler is guaranteed to be already active when > static object constructors are being executed. OK, I agree that this is cleaner, as long as the user only has to supply a definition when BOOST_ENABLE_ASSERT_HANDLER is defined. > there is no explicit support for throwing exceptions, and no standard > exception class is defined. (Although it is trivial to define a handler > that throws.) This is intentional. I don't believe that we, at Boost, want > to encourage this particular programming practice (assertions that throw.) I disagree, on two counts: 1. I've dealt with enterprise systems that do some run-time checks, but for which crashing and core-dumping is not an option. In this case it is preferred to abort the transaction (throw an exception), log the error, and get on with handling other transactions. 2. A number of the Boost libraries currently throw exceptions for logical errors. During development, I would rather that these do an assert(), so I can inspect the core dump with my debugger. Rather than fight over which is the correct behavior, it seems preferable to simply make it a user option. I've been counting on Boost Assert to provide that functionality. One might argue that a user can always get throwing behavior by using BOOST_ENABLE_ASSERT_HANDLER, but I am of the opinion that one should provide some standard options for commonly-desired behavior. If you like, this could be in a separate header that #include's . Now I'll levy one criticism against my own Boost Assert proposal: If you want assertions checked and exceptions thrown when they evaluate false for a production system, then you probably don't want to do any expensive tests. However, during development you probably want to turn on all the checking and debugging options you can. A distinction needs to be made between "light" tests and "heavy" tests; the option to throw an assertion probably only makes sense for "light" tests. > there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. I included BOOST_ASSER_MSG because its equivalent in STLport seemed to be useful as I scanned through that code. I don't have any experience in using STLport myself, though. For those who have used STLport's debug mode, how useful have you found the additional error message information on failed debug assertions? BTW, if BOOST_ASSERT_MSG is included, we'll have to make sure that this is still a no-op when BOOST_ENABLE_ASSERT_HANDLER is not defined and NDEBUG is. In particular, we have to make sure that the error message doesn't get printed out (the assert() already turns into a no-op). ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Property_map docs
Hi Edward, What you say below is an excellent suggestion, and I'll add that to the introduction in the docs for property map. Best Regards, Jeremy --On Thursday, November 14, 2002 4:23 PM -0500 Edward Diener <[EMAIL PROTECTED]> wrote: I would still say to anyone willing to listen that the doc should spell this out, ie. "all these concepts are for you the implementor to put together to create the generic functions that work using the categories mentioned. There is no implementation here." If I had read that I might still have been interested in the concepts as pure ideas, but I would have probably moved on pretty quickly, or further looked into the BGL to see what was a practical implementation of this concept, but I would not have posted anything here regarding the doc which I clearly didn't understand and couldn't make heads or tails out of. It was my frustration about reading the pieces of what I though was an implementation, and not having any idea how these pieces were supposed to fit together to form some sort of reality, that led to my frustration and initial post. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Property_map docs
OK, I completely missed the fact that there is just a concept there and not an implementation. I mistakenly believed that some implementation was behind this rather than just a generalized "here are the ideas, generalized functions and classes, and types recommended, now make it work for you if you like the concept of it." I don't see the point of that without some actual reality of how it all comes together but that's fine with me and my practical bent in this matter is evidently wrong for the situation. Even in the case of STL iterators as the glue between algorithms and containers, there is the proviso that if one creates an iterator for a container of a particular category which follows certain implementation details, then this will work for certain algorithms which expects that "type" of iterator. So there is some reality behind it in the form of algorithms which exhibit functionality in the STL. Naturally to me I thought there has to be some get(), put(), operator[] reality behind property map to make the concepts work. I didn't realize that this reality was up to the implementor to write for his own property map. I admit that I don't see how anyone can infer that from the docs, but evidently others understand all this immediately and see the doc as being transparent in this regard. I would still say to anyone willing to listen that the doc should spell this out, ie. "all these concepts are for you the implementor to put together to create the generic functions that work using the categories mentioned. There is no implementation here." If I had read that I might still have been interested in the concepts as pure ideas, but I would have probably moved on pretty quickly, or further looked into the BGL to see what was a practical implementation of this concept, but I would not have posted anything here regarding the doc which I clearly didn't understand and couldn't make heads or tails out of. It was my frustration about reading the pieces of what I though was an implementation, and not having any idea how these pieces were supposed to fit together to form some sort of reality, that led to my frustration and initial post. "David B. Held" <[EMAIL PROTECTED]> wrote in message news:ar11in$b9j$1@;main.gmane.org... > Edward Diener wrote: > > > [...] > > The problem is that property map is presented separately from the BGL. > > Therefore a valid assumption would be that one could understand how it > > works separately from the BGL. > > But not necessarily that one could understand how it works the first > time you looked at the docs. I have a modern physics textbook from a > class I took in college. I like to read it now and then. But I can > turn to any number of chapters, read them five times, and still have no > meaningful understanding of what is written. The text is not poorly > written, and I am not an idiot (though I might have a hard time finding > people to vouch for that!). The problem is that I have weak calculus > skills, and not enough physics background for the book to be more > comprehensible. Sometimes, I just like to read the sidebars that > describe an application of the principles to a real problem, and pretend > that I understand what's going on. Since I'm not a mathematical > prodigy, it is not feasible for me to read a bunch of PDEs and say: > "Well, duh! That's obvious!" In the same way, my understanding is that > the Property Map library is not a library like the RegEx library. There > are no headers to be included, and no source files to be built, any more > than the Iterator concept requires headers or source files. etc. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Property_map docs
Edward Diener wrote: [...] The problem is that property map is presented separately from the BGL. Therefore a valid assumption would be that one could understand how it works separately from the BGL. But not necessarily that one could understand how it works the first time you looked at the docs. I have a modern physics textbook from a class I took in college. I like to read it now and then. But I can turn to any number of chapters, read them five times, and still have no meaningful understanding of what is written. The text is not poorly written, and I am not an idiot (though I might have a hard time finding people to vouch for that!). The problem is that I have weak calculus skills, and not enough physics background for the book to be more comprehensible. Sometimes, I just like to read the sidebars that describe an application of the principles to a real problem, and pretend that I understand what's going on. Since I'm not a mathematical prodigy, it is not feasible for me to read a bunch of PDEs and say: "Well, duh! That's obvious!" In the same way, my understanding is that the Property Map library is not a library like the RegEx library. There are no headers to be included, and no source files to be built, any more than the Iterator concept requires headers or source files. When I first saw the STL in use, I didn't understand how it worked, or what its advantages were. I had no clue why anyone needed iterators. Had I seen a technical discussion of how to produce a standard-conforming iterator, it would have been worthless to me, no matter how well written. The problem is that I didn't know what iterators were all about. Only after seeing many concrete instances of iterators did I begin to see why they were useful. When I started toying with STL container implementations, I saw the iterator classes, but more or less treated them like black boxes. Now, I feel I could write a custom container and conforming iterators from scratch. But it would have been no more reasonable for me to demand a clear and concise explanation of the Iterator concept as an STL novice than it is for someone to demand a clear and concise explanation of the Property Map concept as a BGL novice. [...] I will say that no matter how poor the documentation seems to me, it is probably on another level which I don't understand and which others can easily figure out without any more specific explanation. I apologize to all concerned and will simply bypass such implementations in the future when the language of it is beyond my understanding. I thought that by criticizing there would be others who might agree that the documentation is not adequate for an intelligent C++ programmer to grasp, and there would be an effort by either Mr. Siek, or someone else who understands property map, to improve it and make it more understandable. [...] I'll be the first to admit that I didn't understand what the Property Map was all about the first time I looked at it. And the second. And the third. And I'll admit that I was frustrated that there wasn't a header file I could look at for a reference implementation. And maybe the docs could be improved. But the fact of the matter is, programming is evolving before our eyes. I like to say that you don't understand a concept until you can explain it to a five year old. That obviously is a bit optimistic, but the point is this: the best instructors are the ones who can lecture freshmen, as well as Ph.Ds and Nobel laureates. And that's because they understand the concepts so well, they can relate them to the most mundane experiences. I don't think many of the new ideas in programming, especially in C++ template metaprogramming, are mature enough for anyone to have that level of understanding. The lack of good C++ template books says volumes. I'm sure Jeremy and others had to make up new concepts and ideas as they went along, building the beast that is the Graph Library. The Property Map just happened to be one of those unplanned side-products. Yes, the documentation implicitly targets those "in the know". No, I doubt that was intentional. Understanding how Property Map works requires the same kind of paradigm shift involved in understanding how Iterator or Functor works. The C++ template engine creates a metalanguage that operates on syntactic form, rather than on concrete semantics. This is why concepts are described in terms of valid expressions, rather than function or type signatures. This notion is not always easy to grasp, and I still struggle with it quite a bit. The idea of creating a metatype that is only a concept, and not something we can write in code can be frustrating. But the fact of the matter is, every real iterator *type* is an *instance* of the metatype *Iterator*. In the same way, every conforming get()/put() *definition* is an *instance* of the metatype *Property Map*, even if they are them
Re: [boost] Re: Serialization Submission version 6
David Abrahams said: > "Eric Woodruff" <[EMAIL PROTECTED]> writes: > >> type_info is not portable in the slightest. > > There are lots of applications where that doesn't matter. And with a > little postprocessing, the type_info::name() produced by most > compilers could easily be normalized into a common format. The trouble is that serialization requires an identifier that's persistant across application runs. type_info by itself doesn't help here, because you can't persist the type_info instance even if it were gauranteed to compare across runs (obviously it's not). type_info::name() is so underspecified that you can't be sure it won't give you the same string for every type. More importantly, in practice (i.e. implementations do this), type_info::name() will often give you strings that are *not* unique, rendering it worthless for this domain. Can type_info::name() be useful? Yes, provided the implementation did something useful, but it's not portable, and not useful for the task at hand. BTW, there's a LOT to be said for specifically supplying an identifier when implementing a persistence/serialization library, even though it means tedious busy work. Specifically, it allows you to insure the id is valid across multiple programs, regardless of how the implementation might auto-magically generate an identifier. I'd recommend choosing a "large integer" representation instead of a string, however, since it will take less space to represent externally. The GUID type is actually a fairly good choice here. William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::graph - incorrect answers with dikjstra_shorts_paths
I'm using boost::graph to model dependencies between files (much like the
File Dependency example in the documentation.) I've been successfully able
to do topological sorts, traversals with visitors, etc., but I am unable to
get the parallel example to work correctly (that is, assigning time slots to
files that signify the earliest time slot in which they can be executed.)
The code I'm using to calculate parallel tasks looks like:
/**
* Outputs all the tasks as a pair that contains both the task name and
an integer that
* represents the earliest timeslice at which a task can be executed
given its dependency
* constraints. Effectively, all tasks with the same timeslice can be
executed in paralell.
*
* @param iter an output iterator
*/
template< class OutputIterator >
void parallel_tasks( OutputIterator iter )
{
using boost::dijkstra_shortest_paths;
using boost::property_map;
using boost::vertex_distance;
using boost::vertex_distance_t;
using boost::vertices;
using std::greater;
// marcja(all): in_degree is a measure of how many edges point into
a particular vertex. If
// a vertex has in_degree 0, it is a root vertex. We use this
information below when
// calculating the Dijkstra shortest paths. The following loop
cycles through each vertex
// and increments the in_degree of any other vertices it points to.
std::vector< int > in_degree( num_vertices( graph_ ),
0 );
Graph::vertex_iterator i, iend;
Graph::out_edge_iteratorj, jend;
for( tie( i, iend ) = boost::vertices( graph_ ); i != iend; ++i )
{
for( boost::tie( j, jend ) = out_edges( *i, graph_ ); j != jend;
++j )
{
in_degree[ boost::target( *j, graph_ ) ] += 1;
}
}
property_map< Graph, vertex_distance_t >::type times = get(
vertex_distance, graph_ );
for( tie( i, iend ) = vertices( graph_ ); i != iend; ++i )
{
if( in_degree[ *i ] == 0 )
{
boost::dijkstra_shortest_paths(
graph_,
*i,
distance_map( times ) .
distance_compare( greater< int >() ) .
distance_inf( 0 ) .
// values other than zero, particularly the default
// of numeric_limits< D >::max(), only seem to change
// the initial value of D for each vertex
distance_zero( 0 )
);
}
}
using boost::vertex_name;
using boost::vertex_name_t;
property_map< Graph, vertex_name_t >::type names = get( vertex_name,
graph_ );
for( tie( i, iend ) = vertices( graph_ ); i != iend; ++i )
{
iter++ = make_pair( names[ *i ], times[ *i ] );
}
}
My program outputs, for example:
talisker> load taskfile
Thu Nov 14 14:42:26 2002 info: loading taskfile
tasks (count: 9)
calibrate_shiftedvol_mtgerate
create_directories
generate_base_and_YCshifted_grids
generate_shiftedvol_grids
get_data_from_crunch
import_yield_curves
run_base_calibration
run_shiftedvol_calibration
set_variables
dependencies (count: 13)
get_data_from_crunch depends on create_directories
import_yield_curves depends on create_directories
calibrate_shiftedvol_mtgerate depends on generate_shiftedvol_grids
import_yield_curves depends on get_data_from_crunch
run_base_calibration depends on get_data_from_crunch
run_shiftedvol_calibrationdepends on get_data_from_crunch
generate_base_and_YCshifted_grids depends on import_yield_curves
generate_shiftedvol_grids depends on import_yield_curves
run_base_calibration depends on import_yield_curves
run_shiftedvol_calibrationdepends on import_yield_curves
generate_base_and_YCshifted_grids depends on run_base_calibration
generate_shiftedvol_grids depends on run_shiftedvol_calibration
create_directoriesdepends on set_variables
talisker> show execution plan
sorted tasks
set_variables
create_directories
get_data_from_crunch
import_yield_curves
run_shiftedvol_calibration
run_base_calibration
generate_shiftedvol_grids
generate_base_and_YCshifted_grids
calibrate_shiftedvol_mtgerate
parallel groups (count: 9)
set_variables 0
create_directories 1
get_data_from_crunch2
import_yield_curves 3
generate_base_and_YCshifted_grids 4
run_base_calibration4
run_shiftedvol_calibration 4
generate_shiftedvol_grids
[boost] Re: lexicalCompare
On 14 Nov 2002 12:40:38 +, Anthony Williams
<[EMAIL PROTECTED]> wrote:
>I have uploaded lexical_compare.hpp to the yahoo files area. It contains
>implementations of the function template lexicalCompare.
Just a little comment and a couple of questions. The former is
actually just a matter of personal preference, so don't feel qualms
about ignoring it (well, not that the same advice isn't valid for the
questions too :-)
I would write the body as:
for (...) {
if(*first1 < *first2)
return -1;
else if(*first2 < *first1)
return +1;
}
if(first2 != last2)
return -1;
else if(first1 != last1)
return +1;
else
return 0;
The difference is in the order of the out-of-loop tests. Since we test
what is *not* exhausted (or empty since the beginning) I prefer to
check the second sequence first, so that the order of the tests that
give -1 is the same inside and out of the loop. In other words I
prefer to see first whether the first sequence is lexicographically
less. BTW once you rewrite it as above you realize that you can
further simplify it as:
for (...) {
if(*first1 < *first2)
return -1;
else if(*first2 < *first1)
return +1;
}
if(first2 != last2) // (*)
return -1;
return first1 != last1;
The questions are: a) as you know the SGI STL has such a template for
long time (lexicographical_compare_3way). Did you deliberately choose
a different name? Why? b) Did you really have problems without the
casts?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
- Original Message - From: "Peter Dimov" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 3:48 PM Subject: Re: [boost] Proposed Boost Assert -- once again > [snipped] > > what is the intended audience of > BOOST_ASSERT, Boost library developers or "end users"? > Good question! I think that users would use BOOST_ASSERT in their own 'low-level' library code. For example, I have an application-level Defect Manager with assertion facilities, but it is not suited for general purpose low-level functions (say, generic algorithms) since it requires external linking to the manager's facilities. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Review
Robert Ramey wrote:
Alberto Barbati wrote
Please note that the "registry" class I described *does not* attempt to
solve the broader issue of UUIDs I read about in the discussion between
you and Vladimir. My proposal is just a way to separate the
"registration" part from the "serialization" into two different
compontents. Still the classes will be matched according to their
registration order, as it happens now. I am ready to discuss the
opportunity and/or usefulness of this approach, but I don't see the
reason why this could not be done.
I considered this approach and found the following problem
It seems from the objections you raise that I did not explain myself
well enough. Before answering to them, I think a code snippet would
help. Consider this code, that uses current implementation:
---begin code
std::ofstream s("...");
boost::oarchive a(s);
a.register_type();
a.register_type();
a.register_type();
a.register_type();
// do serialization
---end code
What I am suggesting is to allow, possibly in addition to that form, the
following form:
---begin code
boost::serialization_registry r;
r.register_type();
r.register_type();
r.register_type();
r.register_type();
std::ofstream s("...");
boost::oarchive a(s, r); // in the body of the constructor an
// equivalent of register_type()
// is immediately called 4 times
// do serialization
---end code
I am *not* suggesting to change in *any way* the serialization process.
The purpose of serialization_registry is just to allow for a finer
granularity of responsibilities.
> a) register all the types in the global collection in the archive.
> bad idea - this would require that the reading program register
> all the types of the writing program. An intolerable requirement
With my approach you are going to register the same types you would
register anyway. Not one less, not one more. Why would it be intolerable?
> b) register types as needed as the library is written
> wouldn't work - on loading, we wouldn't know which types to register
> c) after creating the archive, append a "registration file" on loading,
> process the "registration file first. In my view this cure is worse
> than the disease.
The types are going to be physically output in exactly the same way as
it's being done by current implementation. So this two objections do not
apply.
So you may be wondering, what's the point in having this registry class?
There are two main advantages:
1) the module that sets up the registry can be distinct from the one
that effectively performs the serialization. This can solve a lot of
dependency issues.
2) the registration can be done in *one* place for *both* input and
output. With current implementation, the registration code will be
duplicated and duplication is always a bad thing. Imagine yourself
trying to keep two (possibly very) long lists of register_type calls
synchronized.
I'm still at a loss. Aside from addressing the "classic" above, what exactly
do you recommend I do? How about if I change the wording to specify
that the library supports wide streams and leave unicode out of it?
Yes, it all boils down to change the wording as you said: you just can't
mention Unicode. I got a little carried away because I'm working on the
subject and I'm having a hard time getting people aware of the issue. I
apologize for that.
On a different topic, I found a portability issue. The current
implementation record in the archives the size of the basic types int,
long, float and double. This gives you a *false* sense of security that
the "writing" and "reading" platform agree on the type size.
this is for the native binary archive which is explicitly described as
being non-portable. It was included because some users felt it
would be more efficient. It has no pretensions at all to portability.
Knowing that some one will ignore this admonishment and
try to move such a binary to another machine architecture,
Included free detection so that it would crash in a more
graceful manner.
All right, but still the size_t issue with read_string/write_string is a
bug, as it does not involve cross-platform. With current implementation
a program will fail reading its own serialized strings on a least one
plaform (i64).
Alberto Barbati
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
- Original Message - From: "Peter Dimov" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 1:32 PM Subject: Re: [boost] Proposed Boost Assert -- once again > - there is no explicit support for throwing exceptions, and no standard > exception class is defined. (Although it is trivial to define a handler that > throws.) This is intentional. I don't believe that we, at Boost, want to > encourage this particular programming practice (assertions that throw.) > AFAIK, the differences between abort and throw are two-fold. On one hand, there are platform/compiler-dependent differences. Some enviroments (mostly Unix-like) don't allow you to get context information at the point of the throw, but, OTOH, supply a core-dump in the case of abort(). On these enviroments, abort() is clearly superior. Other enviroments (Windows) do allow you to get context information at the point of the throw and do not supply a *textual* core-dump for post-morten debugging (although you can use JIT). On this enviroment, throw is clearly superior. On the other hand, there are application level differences. Some applications find much better to abort *just the current task* in case of a library failure. In many cases, those failures are far from catastrophic and the application can keep running normally without much trouble. In these applications, even during a debug session it might be useful to let the application keep running because the programmer might need do something else before finally aborting (such as testing other tasks or saving documents). This is a typical scenario with event driven applications with builtin fault tolerance. There are also critical applications which simply *cannot* just abort in case of a failure. Therefore, I conclude that there is not a unique preferable way to deal with assertions. On the application-level, user needs are so varied that the best we can do is to provide a hook so that the user can do whatever she needs to do. This role is well played by "assertion_failed()". On the library-level, the best choice is IMO given by the target platform. For example, if you are targeting Borland on Windows, like me, then abort() is a very bad choice since it leaves no information whatsoever. An exception, on the other hand, is caught by the compiler right at the throw and I can see all I need to spot the problem. But on most Unix-like systems, the situation is exactly the other way around: abort() gives you a core-dump while an exception unwinds the stack *before* you get a chance to see what happened. Therefore, I think that a good choice would be to have a default assertion behaviour based on the target platform. How to supply a target-dependent default definition and at the same time allow the user to override it easely I'm not sure. It appears that Kevin Van Horn's proposal might suite better my criteria. > - there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the > main purpose of BOOST_ASSERT is to replace the standard assert, and since > the file/line/function supply enough information, I haven't provided a > BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one, either. > I've found additional textual information quite useful in many cases, so I'd vote for including the _MSG variant. Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
From: "Rob Stewart" <[EMAIL PROTECTED]> > From: "Peter Dimov" <[EMAIL PROTECTED]> > > > > #elif defined(BOOST_ENABLE_ASSERT_HANDLER) > > > > #include > > I don't follow what this is about. The "handler," as I > understand it, is assertion_failed() declared below, so why this > header? boost/current_function.hpp defines the BOOST_CURRENT_FUNCTION macro. > > - there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the > > main purpose of BOOST_ASSERT is to replace the standard assert, and since > > the file/line/function supply enough information, I haven't provided a > > BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one, either. > > We find it invaluable to provide explanatory text along with the > expression that failed. We often build strings -- at runtime -- > that provide additional context information and description in > the message. Interesting perspective. The question that springs to mind is: would you abandon your ASSERT macro in favor of BOOST_ASSERT_MSG, if it existed? Why would you want to do that? IOW, what is the intended audience of BOOST_ASSERT, Boost library developers or "end users"? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
Kevin S. Van Horn wrote: Looks like I may be wrong about the C++ Standard guaranteeing at least 32 bits to signed/unsigned int. I know I read this before, and I've seen it claimed on a web site, but I can't find it in the Standard. Maybe I read it in the draft Standard, and it didn't make the final cut. I think what you were looking for is footnote 39: 3.9.1/2 says that "Plain ints have the natural size suggested by the architecture of the execution environment (footnote 39 that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header .)" limits.h is defined in 5.2.4.2.1 of the C89 standard (which I don't have a copy of) BUT 5.2.4.2.1/1 of the C99 standard says that an int must be able to support values in the range INT_MIN to INT_MAX, which must be at least -32767 and 32767, or 16 bits. I imagine that 5.2.4.2.1 of the C89 standard says the same thing. -- --- Kevin Lynchvoice: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: [EMAIL PROTECTED] Boston, MA 02215 USA http://budoe.bu.edu/~krlynch --- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cyclic buffer
From: Jan Gaspar <[EMAIL PROTECTED]> > > This is something different - it is an iterator; if it reaches an end of the >container it shifts to its beginning. Cyclic buffer is a > container with different capabilities. I can send it to you, if you want. Of course it is. However, since your circular buffer is merely adapting a deque, you could just as well use Gennadiy's iterator adapter to adapt the relevant (probably begin() and end()) iterators of a deque or vector or You could even change your implementation to use Gennadiy's iterator adapter. Your class could be just a deque and an adapted iterator. > "Neal D. Becker" wrote: > > > This is from Gennadiy Rozental. I believe this is the latest > > version. Please correct me if not. Since it is small, I'll just post it here: > > ... -- Rob Stewart [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
Looks like I may be wrong about the C++ Standard guaranteeing at least 32 bits to signed/unsigned int. I know I read this before, and I've seen it claimed on a web site, but I can't find it in the Standard. Maybe I read it in the draft Standard, and it didn't make the final cut. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comments on Boost Any
These comments apply to release 1.29.0.
Documentation and specification comments
1. Why does any_cast(x) return V instead of V & or V const &? This forces
me to make a copy when I may not need one.
2. The "Synopsis" in the documentation omits the pointer versions of any_cast.
3. The ValueType requirements are unnecessarily strong. The second
requirement states:
"A ValueType is optionally Assignable [23.1]. The strong exception safety
guarantee is required for all forms of assignment."
The implementation never calls an assignment operator on the ValueType,
however. Perhaps you meant to say that assignment to an object of type
boost::any satisfies the strong exception safety guarantee. (Requirements
are conditions that users must ensure; guarantees are promises that
implementers make.)
4. Minor grammatical nit in the documentation, under "ValueType requirements":
"As the emphasis of a value lies in its state not its identity, values..."
should be
"As the emphasis of a value lies in its state, not its identity, values..."
(comma added).
5. Documentation, under "Modifiers":
any & swap(any & rhs);
Non-throwing exchange of the contents of *this and rhs.
This fails to specify what reference is returned. I suggest adding,
"Returns rhs."
6. any_cast throws a bad_any_cast exception if the wrong type is given. There
are, however, two cases to be distinguished here:
a. The programmer anticipates the possibility of a type mismatch -- the
program logic does not, and is not intended to, rule out the possibility
-- and wishes to handle that case separately, in a catch clause.
b. The programmer believes that the program logic guarantees that there
cannot be a type mismatch. Any type mismatch is, in fact, a bug in the
program.
The current behavior is appropriate for case (a), but not for case (b).
For case (b) something like the proposed Boost Assert would be preferable:
programmer can choose, via preprocessor symbols, to have the
program crash and core dump (to aid debugging), or to throw an exception
giving the file and line number where the error was detected, or to simply
not check at all (performance over safety). At the end of this
message I've included a patch that provides for case (b), via a function
known_any_cast().
Implementation comments
---
6. The copy assignment operator is implemented as
any & operator=(const any & rhs)
{
any(rhs).swap(*this);
return *this;
}
Andrei's comments about avoid unnecessary copying apply here: the
alternative
any & operator=(any rhs)
{
rhs.swap(*this);
return *this;
}
avoids a copy when the right operand of assignment is an unnamed temporary,
and otherwise does the same number of copies as the existing implementation.
Note, however, that the value assignment template
template
any & operator=(const ValueType & rhs)
{
any(rhs).swap(*this);
return *this;
}
should remain just as it is; copying rhs within the body of the ctor
(in the any ctor) is unavoidable.
7. In the following lines
template
ValueType * any_cast(any * operand)
{
return operand && operand->type() == typeid(ValueType)
? &static_cast *>(operand->content)->held
: 0;
}
the unary "&" preceding "static_cast..." should be replaced by
boost::addressof, in case an overload of operator&() is defined for
ValueType.
=
Context diff for patch to add known_any_cast():
*** /opt/include/boost/any.hpp Sun Jan 20 13:09:43 2002
--- any.hpp Thu Nov 14 11:59:47 2002
***
*** 11,17
#include
#include
! #include "boost/config.hpp"
namespace boost
{
--- 11,19
#include
#include
! #include
! #include
! #include
namespace boost
{
***
*** 173,178
--- 175,202
return *result;
}
+
+ template
+ ValueType * known_any_cast(any * operand)
+ {
+ BOOST_ASSERT(operand && operand->type() == typeid(ValueType));
+ return boost::addressof(
+static_cast *>(operand->content)->held
+ );
+ }
+
+ template
+ const ValueType * known_any_cast(const any * operand)
+ {
+ return known_any_cast(const_cast(operand));
+ }
+
+ template
+ ValueType known_any_cast(const any & operand)
+ {
+ return *known_any_cast(&operand);
+ }
+
}
// Copyright Kevlin Henney, 2000, 2001, 2002. All rights reserved.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
From: "Peter Dimov" <[EMAIL PROTECTED]>
>
> #elif defined(BOOST_ENABLE_ASSERT_HANDLER)
>
> #include
I don't follow what this is about. The "handler," as I
understand it, is assertion_failed() declared below, so why this
header?
> namespace boost
> {
>
> void assertion_failed(char const * expr, char const * function, char const *
> file, long line); // user defined
>
> } // namespace boost
>
> BOOST_ASSERT now uses the standard assert by default, something that was
> decided during our earlier discussions. I've introduced separate
> BOOST_DISABLE_ASSERTS and BOOST_ENABLE_ASSERT_HANDLER macros since relying
> on the BOOST_DEBUG "magic values" to control behavior seemed inferior.
It certainly seems appropriate.
> - assertion_failed is declared but left undefined, the user is expected to
> supply a definition. Compared to a set_assert_handler approach, this has the
> advantage that the handler is guaranteed to be already active when static
> object constructors are being executed.
This is a very good approach.
> - there is no explicit support for throwing exceptions, and no standard
> exception class is defined. (Although it is trivial to define a handler that
> throws.) This is intentional. I don't believe that we, at Boost, want to
> encourage this particular programming practice (assertions that throw.)
The good thing about the assertion_failed() approach is that the
library user can make this choice himself.
> - there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the
> main purpose of BOOST_ASSERT is to replace the standard assert, and since
> the file/line/function supply enough information, I haven't provided a
> BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one, either.
We find it invaluable to provide explanatory text along with the
expression that failed. We often build strings -- at runtime --
that provide additional context information and description in
the message.
--
Rob Stewart [EMAIL PROTECTED]
Software Engineer http://www.sig.com
Susquehanna International Group, LLP using std::disclaimer;
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Property_map docs
"Anthony Williams" <[EMAIL PROTECTED]> wrote in message news:15827.3.343000.937688@;gargle.gargle.HOWL... > Edward Diener writes: > > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > > message news:15826.2782.569000.619636@;gargle.gargle.HOWL... > > > Edward Diener writes: > > > > Finally I would like a non-partisan answer from you to my next question > > and > > > > I am perfectly willing to be wrong and accept the fact that my lack of > > > > understanding of "concept" based explanations are at fault. Do you feel > > that > > > > the answers to my 2 questions are readily apparent to most intelligent > > C++ > > > > programmers from reading the property map docs ? > > > > > > As Jan Langer pointed out, there are specific pages for each of the > > property > > > map categories. If you missed these you will have difficulty piecing > > > everything together. > > > > No, I saw them from the beginning. I just didn't ( and still don't ) > > understand how they fit in with some sort of global get(), put(), and > > operator[] template functions. > > operator[] has to be a member function if it exists at all, unless the > built-in operator[] is sufficient. > > get() and put() may or may not be global, and may or may not be > templates. They must be implemented for each property map so that the > expressions get(property_map,key_value) and > put(property_map,key_value,new_value) compile and work OK. This means that > they may be global, or they may be in an associated namespace of the property > map or key value types, and found by ADL. > > The parameter types may or may not exactly match the types of the property map > etc., provided that the functions can be found, and the supplied arguments can > be converted to the required parameter types --- e.g. if the property map is > actually a pointer to X, then the real parameter for get() could be a pointer > to Y, if Y is an unambiguous public base of X --- and provided that overload > resolution finds the correct function. I would expect in the common case, that > the get() and put() functions are supplied in the same namespace as a property > map type, and the parameter types exactly match the types of the property map > and key value, give or take a const&, but this is not necessarily the case. > > The presence of a template get() will probably be an impediment if the > parameters are not an exact match for the supplied types, since deduced > template parameters have a nasty tendency to exactly match the supplied > arguments, and may therefore be picked in preference, or cause an ambiguity. Then the get(), put(), and operator[] values are purely user defined and there are no common implementations for these which automatically work with any property map. Everything having to do with property maps are just a generalized concept of how this should work so that a given property map has effective get(), put() and operator[] functions which an end user can use to associate a value with a property ( key ). Whatever implementations exist in the header files are just specific types of property maps which have already been developed based on the different categories. Is this a correct understanding of the property map concept ? If so, it is something I completely missed from the docs, but which others were able to understand immediately. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed bit_struct submission to Boost
David Abrahams writes: > Looks cool. I don't usually need such a thing, though. Could you give > some examples of likely use cases? The impetus for bit_struct was a discussion with a local business on possible student library projects that would benefit the business. This company writes a lot of embedded software. They are dealing with a network protocol that allows them to pack any number of parameters into a message of exactly eight bytes. Note that byte order within multibyte integers is an issue I have not addressed with bitstruct; if one wishes to send a bitstruct over the network, then either the sender and receiver must have the same integer sizes and byte orders, or you need an additional facility to put bytes into a standard order (like the Unix htonl, htons, ntohl, and ntohs functions, but templatized.) This kind of thing might also be useful in writing memory allocators, where you want to tightly pack information into a small header for a block of memory. It might also be useful in implementing tagged data for dynamically-typed languages. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
From: "Peter Dimov" <[EMAIL PROTECTED]>
> From: "Kevin S. Van Horn" <[EMAIL PROTECTED]>
> > It's been six days since I posted this, without a single response, so
I'm
> > going to try again. Based on earlier discussions, I thought there might
> > be some interest in this. Does anyone have any problems with the
proposed
> > interface? Should I turn this into a formal proposal for submission to
> > Boost? Peter, how does this compare with the changes to
> > you were planning to do / are doing?
>
> Sorry, I've been offline. I'll try to make the changes to assert.hpp ASAP
so
> we can base the discussion on the new version.
The new boost/assert.hpp is now in CVS, I'll copy it below for convenience:
#undef BOOST_ASSERT
#if defined(BOOST_DISABLE_ASSERTS)
# define BOOST_ASSERT(expr) ((void)0)
#elif defined(BOOST_ENABLE_ASSERT_HANDLER)
#include
namespace boost
{
void assertion_failed(char const * expr, char const * function, char const *
file, long line); // user defined
} // namespace boost
#define BOOST_ASSERT(expr) ((expr)? ((void)0):
::boost::assertion_failed(#expr, BOOST_CURRENT_FUNCTION, __FILE__,
__LINE__))
#else
# include
# define BOOST_ASSERT(expr) assert(expr)
#endif
The main difference between this version and the old assert.hpp is that
BOOST_ASSERT now uses the standard assert by default, something that was
decided during our earlier discussions. I've introduced separate
BOOST_DISABLE_ASSERTS and BOOST_ENABLE_ASSERT_HANDLER macros since relying
on the BOOST_DEBUG "magic values" to control behavior seemed inferior.
The main differences between this header and your proposed version are:
- assertion_failed is declared but left undefined, the user is expected to
supply a definition. Compared to a set_assert_handler approach, this has the
advantage that the handler is guaranteed to be already active when static
object constructors are being executed.
- there is no explicit support for throwing exceptions, and no standard
exception class is defined. (Although it is trivial to define a handler that
throws.) This is intentional. I don't believe that we, at Boost, want to
encourage this particular programming practice (assertions that throw.)
- there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the
main purpose of BOOST_ASSERT is to replace the standard assert, and since
the file/line/function supply enough information, I haven't provided a
BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one, either.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization Submission version 6
- Original Message - Eric Woodruff wrote: > type_info is not portable in the slightest. I realize that. I just pointed out that it's not so convenient to have user-supplied string ids because of the template classes. Regards, -Vahan > "Vahan Margaryan" <[EMAIL PROTECTED]> wrote in message > news:003401c28bee$7fbc4f40$4f09a8c0@;lan.mosaic.am... > - Original Message - > From: "Robert Ramey" <[EMAIL PROTECTED]> > Sent: Thursday, November 14, 2002 5:45 PM > Subject: Re: [boost] Serialization Submission version 6 > > > > > > > register_cross_program_class_identifier(const char *id="T") > > > > This would be invoked for each class declaration. Now we have > > a portable id associated with each class - exactly what we need. > > Polymorphic pointers would archive this tag and use it > > to determine the proper class to construct on loading. > > > > The default class identifier would be the text representation of the class > name. > > (note: in general not necessarily the same as type_info.name() ) > > which is going to be sufficent for almost all cases. > > The problem that usually arises from this is having to make up class ids for > template classes. type_info does this for you. > > Regards, > -Vahan > > > > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Serialization Submission version 6
Robert Ramey wrote: I believe I have found the an acceptable resolution to the "registration" cunundrum. The whole problem was generated by by the fact that type_info is not portable and in my view never can be and wouldn't help anyway. Hence a function that did class->unique class identifer could not exist. I realize now that we don't really require that such a function exist. How about this. I conjure up something like (pseudo code): register_cross_program_class_identifier(const char *id="T") This would be invoked for each class declaration. Now we have a portable id associated with each class - exactly what we need. Polymorphic pointers would archive this tag and use it to determine the proper class to construct on loading. That would be precisely right. Indeed, I believe this is the scheme I've previously described in terms of type_info -> GUID and GUID -> factory maps. The default class identifier would be the text representation of the class name. (note: in general not necessarily the same as type_info.name() ) which is going to be sufficent for almost all cases. Yes, exactly! I actually believe that type_info is the best form -- I don't know any other way to automatically get the class name. If one has concerns about the universality of his class identifier (e.g. a class named window or some such) or if one wants to do something more ambitious (e.g. plug-in system) he will be free to use any other const string to identify his class by overriding the default. Right, e.g. string representation of COM GUID. explicit invocation of basic_[i|o]archive::register_type would no longer be necessary. I believe this would resolve the whole issue to everyone's satisfaction. Yes, I'm starting to thinking that we'll have a quite good serialization soon. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization Submission version 6
"Eric Woodruff" <[EMAIL PROTECTED]> writes: > type_info is not portable in the slightest. There are lots of applications where that doesn't matter. And with a little postprocessing, the type_info::name() produced by most compilers could easily be normalized into a common format. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Looking for another borland format patch
I continue to make progress with format, but seem to fail most tests the
format a hex value.
In particular, if I want to format an 8 digit hex number to display as:
0x1234
I am currently getting
0x1234
I beleive this is some test code that does roughly something similar to
the library implementation:
int main()
{
std::cout.setf( std::ios::showbase );
std::cout << "BCB hex test: "
<< std::setfill( '0' )
<< std::setw( 8 )
<< std::internal
<< std::hex
<< 0x1234 << std::endl;
}
Is this a correct simplification on the library algorithm for this test
case? I'm not sure about relying on 'internal' to separate 0x from 1234
before padding. Is this the technique format uses? And if so, is it
correct? Or am I missing something else in the library?
[I'm no streams expert, and will happily file a bug report with borland
if someone can quote me a relevent section of the standard, if that is
indeed the case]
--
AlisdairM
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
type_info is not portable in the slightest. "Vahan Margaryan" <[EMAIL PROTECTED]> wrote in message news:003401c28bee$7fbc4f40$4f09a8c0@;lan.mosaic.am... - Original Message - From: "Robert Ramey" <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 5:45 PM Subject: Re: [boost] Serialization Submission version 6 > > > register_cross_program_class_identifier(const char *id="T") > > This would be invoked for each class declaration. Now we have > a portable id associated with each class - exactly what we need. > Polymorphic pointers would archive this tag and use it > to determine the proper class to construct on loading. > > The default class identifier would be the text representation of the class name. > (note: in general not necessarily the same as type_info.name() ) > which is going to be sufficent for almost all cases. The problem that usually arises from this is having to make up class ids for template classes. type_info does this for you. Regards, -Vahan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Serialization Submission version 6
- Original Message -From: "Robert Ramey" <[EMAIL PROTECTED]>To: <[EMAIL PROTECTED]>Sent: Thursday, November 14, 2002 5:45 PMSubject: Re: [boost] Serialization Submission version 6>>> register_cross_program_class_identifier(const char *id="T")>> This would be invoked for each class declaration. Now we have> a portable id associated with each class - exactly what we need.> Polymorphic pointers would archive this tag and use it> to determine the proper class to construct on loading.>> The default class identifier would be the text representation of the classname.> (note: in general not necessarily the same as type_info.name() )> which is going to be sufficent for almost all cases.The problem that usually arises from this is having to make up class ids fortemplate classes. type_info does this for you.Regards,-Vahan
[boost] Re: Quaternions & Octonions - for novices non-mathematians?
Somewhere in the E.U., le 14/11/2002 Bonjour Thanks for the wonderfull reference! I would, of course, see octonions become part of the standard, but there is currently a technical problem: The input operator is grossly difficult to maintain. No sane implemetor (what does that mean for me? :-) ) would want to ship an implementation such as the one I gave. There is a (wonderfully elegant) way out of this problem: use Spirit (this is on my to-do list), but this places a very significant standardization dependency. The problem is similar, but less accute, for quaternions. I believe the standard, in some future form, should also change the complex specification to rely on an explicit (parseable) grammar. To root the chain, I believe an explicit (parseable) grammar for floating numbers and integers should at some point go in the standard as well. This would not restrict the lattitude with wich compilers could find a binary equivalent to a given explicit floating point constant, but would be a step in the right direction with regard to explit constants (see the discution on sclc++...). I would love to write a formal proposal for octonions, as well as for quaternions, but for various reasons (getting my employer to understand that would be time well spent, for instance), I now fear I risk missing the boat... Merci Hubert Holin [EMAIL PROTECTED] "Paul A. Bristow" wrote: > > Ian Stewart, "The Missing Link...", New Scientist p 30, 9 Nov 2002 writes > accessibly about Quaternions & Octonions: > > "The octonions started out as mathmetical curiosities, and were almost entirely > ignored for 150 years, but their time has now come" > > so that I think these can be regarded as mainstream and entirely suitable for > C++ Standard Library. > > Also references for further reading > "The Octonions", John Baez, American Mathemtical Society, vol 39, p 145 (2002) > > Paul > > Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK > +44 1539 561830 Mobile +44 7714 33 02 04 > Mobile mailto:pabristow@;genie.co.uk > mailto:pbristow@;hetp.u-net.com > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
>Dirk Gerrits wrote: >IIRC the old persistance library defined facilities for input and output >using the RFC-1014 XDR: External Data Representation Standard. The new >serialization library doesn't seem to include such archive classes and >leaves it up to the user to write these. >Now I don't mean to dispute the decision, but I'd just like to know what >the rationale for it was. Well, I've been busy. Seriously, I personally had no interest in implementing XDR. a) It didn't add any more portability than using a text file. b) using a text stream permited standard library code to address the mapping between machines - for free and guaranteed correct c) In my opinion wouldn't be any faster Of course all sorts of objects were raised to these views. Worse, everyone wanted their own pet archive format. So I did the natural thing - I punted. The data storage is completelty factored out. I'm waiting for any one of those who told me how easy it is to make a portable XDR archiver to submit a derivation of basic_[i|o]archive. This factoring out actually is a great thing. The data storage itself doesn't even have to be a stream like object. It could be something more interesting like an pipe to another machine or what ever. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] jam_src/boost-jam.spec broken on RH-8.0
new commits have broken the rpm build on RedHat 8.0 + ln -sf bjam-3.1.3 /var/tmp/boost-jam-3.1.3.root/usr/bin/jam + install -m 644 /var/tmp/boost-jam-3.1.3.root/usr/share/doc/boost-jam-3.1.3 install: too few arguments the environment variable BOOST_JAM_DOCS is not setup correctly. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Serialization Submission version 6
I believe I have found the an acceptable resolution to the "registration" cunundrum. The whole problem was generated by by the fact that type_info is not portable and in my view never can be and wouldn't help anyway. Hence a function that did class->unique class identifer could not exist. I realize now that we don't really require that such a function exist. How about this. I conjure up something like (pseudo code): register_cross_program_class_identifier(const char *id="T") This would be invoked for each class declaration. Now we have a portable id associated with each class - exactly what we need. Polymorphic pointers would archive this tag and use it to determine the proper class to construct on loading. The default class identifier would be the text representation of the class name. (note: in general not necessarily the same as type_info.name() ) which is going to be sufficent for almost all cases. If one has concerns about the universality of his class identifier (e.g. a class named window or some such) or if one wants to do something more ambitious (e.g. plug-in system) he will be free to use any other const string to identify his class by overriding the default. explicit invocation of basic_[i|o]archive::register_type would no longer be necessary. I believe this would resolve the whole issue to everyone's satisfaction. Robert Ramey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposed Boost Assert -- once again
From: "Kevin S. Van Horn" <[EMAIL PROTECTED]> > - Line numbers are unsigned, and not unsigned long, because the C++ Standard > guarantees that unsigned values are at least 32 bits, which should provide > sufficient line numbers for any source file. Does it? Where? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator_adaptors
Anthony Williams <[EMAIL PROTECTED]> writes: > Back in September (or maybe early October) David Abrahams said that he and > Jeremy Siek were planning to have a look at creating a new iterator adaptor > framework at the C++ Standards meeting in Santa Cruz. > > I was just wondering if they managed to find the time, and if so, when we > might get our hands on the code. We're working on it. There's something in the boost sandbox at boost/iterator/* and libs/iterator/*. However, Thomas Witt has proposed some major revisions which I find to be mostly very attractive. We're still haggling over those. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Win32 regressions on main trunk updated
Somewhere in the E.U., le 14/11/2002 Hi John Maddock wrote: > > > Looking at the failure conditions for special functions, for M$VCPP > > v7, it seems that the branch for the case where > > BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is *NOT* defined is taken, but > > this symbol is defined in Boost 1.29.0 for that compiler. Is there a > > problem with the config files for the regression on the main trunk? > > Maybe because your headers don't include the necessary header > ??? What I was wondering about was whether the test machine (not mine, I'm still under MacOS 9.2.2 using CodeWarrior) had its headers properly configured. The released version has BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION defined for that compiler, but the main trunk version behaves as though such is not the case. Ergo, either it was found it should not have been defined, and the "#define" has been deleted between the release version and the main trunk, or the merging of the release trunk into the main trunk left out part of the config headers. Or I missed something... Hubert Holin [EMAIL PROTECTED] > John Maddock > http://ourworld.compuserve.com/homepages/john_maddock/index.htm > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] iterator_adaptors
Back in September (or maybe early October) David Abrahams said that he and Jeremy Siek were planning to have a look at creating a new iterator adaptor framework at the C++ Standards meeting in Santa Cruz. I was just wondering if they managed to find the time, and if so, when we might get our hands on the code. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexicalCompare
I have uploaded lexical_compare.hpp to the yahoo files area. It contains implementations of the function template lexicalCompare. lexicalCompare is analagous to std::lexicographical_compare, except that it returns a 3-way output like strcmp: <0 => first sequence is less than second 0 => first sequence is equivalent to the second >0 => second sequence is less than the first Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bad link on boost site in format docs
The following URL linked on the main Format into-page hits HTTP Error 403 - Forbidden. http://www.boost.org/libs/format/example/ -- AlisdairM Team Thai Kingdom ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] help(boost.python: vc compiler limit)
Kemeng, Please post Boost.Python questions to the C++-sig, as I've previously requested. http://www.python.org/sigs/c++-sig ¿ÂÃÍ <[EMAIL PROTECTED]> writes: > Hi: > > I'm try to convert asn.1 to python. What's asn.1? > I use snacc to convert asn.1 to c++ first, What's snacc? > and then use boost.python to convert c++ to python. > > In this version,when I compile a big file in vc6,compiler report error: > "fatal error C1204:Compiler limit:internal structure overflow" > > What can I do? Thanks! 1. Get a better compiler (preferred). Even VC7 will work. 2. Split up your file into multiple translation units (separate source files). Your module initialization function can call a function defined in another source file to expose additional functionality. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Property_map docs
Edward Diener writes: > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > message news:15826.2782.569000.619636@;gargle.gargle.HOWL... > > Edward Diener writes: > > > Finally I would like a non-partisan answer from you to my next question > and > > > I am perfectly willing to be wrong and accept the fact that my lack of > > > understanding of "concept" based explanations are at fault. Do you feel > that > > > the answers to my 2 questions are readily apparent to most intelligent > C++ > > > programmers from reading the property map docs ? > > > > As Jan Langer pointed out, there are specific pages for each of the > property > > map categories. If you missed these you will have difficulty piecing > > everything together. > > No, I saw them from the beginning. I just didn't ( and still don't ) > understand how they fit in with some sort of global get(), put(), and > operator[] template functions. operator[] has to be a member function if it exists at all, unless the built-in operator[] is sufficient. get() and put() may or may not be global, and may or may not be templates. They must be implemented for each property map so that the expressions get(property_map,key_value) and put(property_map,key_value,new_value) compile and work OK. This means that they may be global, or they may be in an associated namespace of the property map or key value types, and found by ADL. The parameter types may or may not exactly match the types of the property map etc., provided that the functions can be found, and the supplied arguments can be converted to the required parameter types --- e.g. if the property map is actually a pointer to X, then the real parameter for get() could be a pointer to Y, if Y is an unambiguous public base of X --- and provided that overload resolution finds the correct function. I would expect in the common case, that the get() and put() functions are supplied in the same namespace as a property map type, and the parameter types exactly match the types of the property map and key value, give or take a const&, but this is not necessarily the case. The presence of a template get() will probably be an impediment if the parameters are not an exact match for the supplied types, since deduced template parameters have a nasty tendency to exactly match the supplied arguments, and may therefore be picked in preference, or cause an ambiguity. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
IIRC the old persistance library defined facilities for input and output using the RFC-1014 XDR: External Data Representation Standard. The new serialization library doesn't seem to include such archive classes and leaves it up to the user to write these. Now I don't mean to dispute the decision, but I'd just like to know what the rationale for it was. Secondly, I have a nit about the documentation. In the reference section about the 'Definition of New Archive Formats' it is said that: 'The archive format is specified by implementing the virtual functions of the base class.' I think it would be clearer if the documentation also stated all those virtual functions that one should implement, so that the user wouldn't have to read archive.hpp. Perhaps a simple example should be provided. Say, a rot13 text stream or something. Regards, Dirk Gerrits ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] help(boost.python: vc compiler limit)
Hi: I'm try to convert asn.1 to python. I use snacc to convert asn.1 to c++ first,and then use boost.python to convert c++ to python. In this version,when I compile a big file in vc6,compiler report error: "fatal error C1204:Compiler limit:internal structure overflow" What can I do? Thanks! kemeng
Re: [boost] Serialization Submission version 6
Robert Ramey wrote:
How's that? I'm I going to use the class from two different problem, I'll use the
same header, and the classes will be in the same namespace.
I'm refering here to a discussion in The C++ Programming Language sections 8.2.5
and section 8.2.8.
It would have helped if you described what is discussed here -- I don't have
the book ready. Anyway, I belive different namespace of the same class makes
sense only for legacy code, and is quite rare.
However, the mention of GUID gives me a new ground for argumentation. Suppose *I* (i.e.
without any help from serialization library), have created two maps:
1. type_info -> GUID
2. GUID -> factory function
I believe this is enough to correctly serialize/deserialize all classes registered
in those two maps. Your plug-in example suggests that load method for the base class
should take care of saving GUID and load method should dispatch to the appropriate
factory function. I think this only requires extra work from me, and is not needed.
In fact, the library might care of it. If a class with declared GUID is saved, than
GUID is safed as well. On loading, if object in archive has GUID, you call appropriate
factory function and then proceed with loading into created object.
Ahhh - now you've hit the nail on the head.
My conclusion is that there can exist no universal function that automatically transforms
type_info into a GUID. This is the fundamental problem.
Suppose we set out to create such a function:
Permit me to include my argument for this point from a previous email
Agree, there's no a *universal* way to tell that two classes are semantically
the same.
Now suppose you have a special situation. For example, a suite of programs
that are in you sole control and you would like to your own "Local cross program
class identifier". The above argument doesn't apply to this situation. For this
I created the example "demo_unregistered_pointers". In this case a GUID
consisting of type_info.name() would work just fine. Archives and code would be portabable
across all compilers. It would work even for plug-ins - as long as you had control
over the naming.
Agh... except that I have to implement some code myself... in particular loading
for base classes. This code would be the same for all base classes, and, therefore,
library can and should take care of it.
As an aside, I double checked into MFC as the details of how it addresses this issue.
Microsoft uses CRuntimeClass basically a wrapper around the class name. This
is written to the archive. On loading, they look it in the table. Basically using the
class name as the GUID. Since this system broke down for COM, the used
the Unique GUID generated by the computer.
These are no news for me.
My intention in the example was to illustrate give you the facility you want
without creating a more fundamental problem for others. Also consider that
this special serialization is required only for base classes of polymophic pointers
not for every class. typically this would be only a very small number
What are the fundamental problems for others? The scheme I've described is
completely optional.
As I was saying all the time, including all of the headers in the project in "main.cpp" is
not a reasonable idea for me.
They don't have to be in main.cpp. you could include them a registeration.cpp
that has a function register_types which you call just after any archive
is created. At least it would all be in one place.
1. I'd still prefer registering a class at the point of declaration/definition, without
creating this super-file.
2. You'd have to call a function in that file after creating all archives. This is
just unsafe: calling ctor should be the only initialization.
3. Now, assume the following situation:
oarchive a ;
register_polymorphic_types(a); // Here 100 classes are registers
a << {polymorphic_pointers) ;
a << {bunch of other data) : // First stored class will have number 101.
You put the generated file aside, and after a month create a new polymorphic
class. Then you do:
iarchive >> a;
register_polymorphic_types(a) // Here 101 class is registered.
a >> {polymorphic_pointers} ;
a >> {other data}: // Here, we see class id 101, which used to be
// first class not-registered in register_poly...
// a month ago, but now: it's last polymorphic
// class.
Unless I'm missing something, but it seems like CLASS IDS ARE NOT STABLE.
This means that if I just add new polymorphic classes, I won't be able
to read previously created archives.
I don't have the time to create a compilable example, but my prior examination of
the code tells me that the above suspicion is true.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
