gmane.comp.lib.boost.devel

Re: [bigint] Integer data type larger than 64 bits?

Kevin Sopp — 2008-08-21T17:29:35

It's an interesting idea. I'm not an ASM expert, I just learned some for mp_int to play around a little. It could be done if the CPU was able to inspect the carry flag automatically after each arithmetic instruction and then issue an interrupt on overflow. Yes, that can be done. I don't know when it will happen. Maybe someone else will do it ;-) Kevin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: GIL: how to convert an any_image_view to its const equivalent?

Philipp Reh — 2008-08-21T17:20:49

Lubomir Bourdev wrote: Hi, Lubomir. Sorry for replying so late. The workaround works fine with gcc-4.3.1 as well. Cheers, Philipp

Re: [1.37.0] branches/release open for merges

Stefan Seefeld — 2008-08-21T17:20:30

I fail to understand what you are saying. As far as I know, there are no 'interface contracts' on trunk. And, adding a new feature in patch A, which a subsequent patch B relies on is certainly a possibility, if not even likely. The point I'm trying to make is that, as far as I can see, there is no dependency tracking between changesets, so it may be hard to tell whether a merge of any changeset from trunk to the release branch will be self-contained, or rely on another merge being done first. Anyways, my main point remains this: The way you treat the 'release branch' is how other projects use 'trunk' for, while what you name 'trunk' is more of a 'sandbox' elsewhere. Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases. Regards, Stefan

Re: [1.37.0] branches/release open for merges

John Maddock — 2008-08-21T17:09:57

Sandboxes are for experimental changes, Trunk is for stable changes that you have tested locally to the best of your ability, but which needs the full regression tests to be run before it's considered "release ready". In fact, the *aim* is to keep Trunk release ready at all times, the trouble is we've found that not to work in practice, as even with the best will in the world unexpected breakages do occur. Separating Trunk and release branch is intended to minimise this kind of unintentional (or down right sloppy!) breakage. It does, been there, experienced that already :-( Actually while it cost me a bit of extra time, it wasn't too bad after all, HTH, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Robert Ramey — 2008-08-21T18:07:29

If this shows up when a merge is made of a library into the release ready branch it should be considered a bug as it must be a break in an interface contract. If this is an obtacle to making this system work - then there is no system that can work. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

John Maddock — 2008-08-21T17:05:26

Or treat (c) as a prerequisite to (a) and (b) ? John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Robert Ramey — 2008-08-21T18:04:43

OK I'll rephase a) When the library is as good as the author THINKS he can make it b) This is easy - when the number of regressions is less than before the change or there is an improvement and no new regressions. re b) Naturally, there can be no regression for a compiler that has never been tested. Hmmm - b) requires some manual investigation / comparison of test results. So I would still recommend b) for improvements and a) for new libraries. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Vladimir Prus — 2008-08-21T16:54:27

Well, (a) is non-verifiable, and (b) is hard to achieve (e.g. you cannot check "in no way worse" for toolsets that are not tested, and "no way worse" might include non-testable things. So, we only have test results for trunk and release branch, and have to decide of merge from trunk and release branch is OK. All I'm asking is whether, assuming I'm otherwise willing to do the merge, if I can arrive at this "OK/not OK" decision without any manual investigation and comparison of test results? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [bigint] Integer data type larger than 64 bits?

Simonson, Lucanus J — 2008-08-21T16:38:47

Kevin wrote: Ah, I see. 32 bit is certainly good enough. Speaking of assembler and platform specific stuff, do you know how to trap integer overflow events in C++ to handle them as exceptions? It would be a big performance advantage to try a calculation that might overflow, catch the overflow exception thrown by the event handler and then execute high precision/complex calculations instead to get the correct answer. This would need to coexist with code that doesn't catch overflow, so the event handler would need to inspect a dynamic policy that informs it whether to ignore or throw in it's currently context. overflow_policy.push(THROW); try { a = b * c * d; } catch overthrow_exception { a = foo(b, c, d); }; overflow_policy.pop(); Kevin wrote: Yes, I was originally thinking a parameterized fixed precision integer that lives on the stack. Something like: template class integer { static const int word_length = bit_width / word_width + 1; word_type vals_[bit_width / word_width + 1]

Re: [1.37.0] branches/release open for merges

Stefan Seefeld — 2008-08-21T16:11:13

This description of 'trunk' sounds more like it should be called 'sandbox' to me. May be that would indeed be a good idea to clarify the process you are promoting. As usual, this may get quite complex if changesets are interdependent. I.e., it may be that one patch that went into trunk only works because of another patch in trunk, but would fail in release without the other there applied first. In any case, thanks for the clarification ! Stefan

Re: [1.35] using binary_oarchive instead of text_oarchive

Robert Ramey — 2008-08-21T17:02:53

you shouldn't have to change anything. Just use: std::ostreamstream ostr(std::io_binary); boost::archive::binary_oarvhice oa (ostr); oa & foo; Robert Ramey Alexander Dong Back Kim wrote: _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Robert Ramey — 2008-08-21T17:00:56

So the question is "When is it OK to merge from the trunk into release?" I see a couple of different possible answers: a) When the library is as good as the author can make it b) When the library is better in at least one way than the current release and in no way worse. That is when releasing the changes will result in an improvement for someone and cause no harm to anyone. c) When tests pass on "release compilers" For a new library I would prefer a). For an improvement/bug fix to and existing library, I would prefer b). Personally, I would never prefer c) since it opens up a whole issue of what it means to be "release platform" which I don't think is a very useful concept in this context. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [fsm review] Not quite a review

Darryl Green — 2008-08-21T15:00:16

This is as close to a review as I am going to have time for. I've had a bit of a look at the code, but still haven't tried to use the library. The code is clear, but I do wonder at the necessity of some of the low level "hacks" used to implement the state "container" used. Could a fusion set not have done the same job? Using the tutorial is ok - it just needs to illustrate some of the mappings from concepts that can be expressed i a UML staechart to your library better/more comprehensively. I wasn't referring to the documentation but to the naming conventions in the library itself. I did not intend to critique the English or the internal consistency of the documentation. Rather I think adopting a terminology consistent with some published standard state machine representation/model such as UML is almost essential. If boost is to ccontain 2 libraries for implementing state machines, there should at least be a clear mapping between concepts in one and the other. Identical terminology should be used wher

Re: [Important] Server outage on Thursday, August 21st

Douglas Gregor — 2008-08-21T14:02:29

On Mon, 2008-08-18 at 16:41 -0400, Doug Gregor wrote: There was a hangup on our end and we were unable to perform the upgrade this time. We will reschedule once we've resolved the issue. - Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [lambda][bind] trivial bind fails when lambda and bind are in the same source file

Jeff Flinn — 2008-08-21T13:26:17

Whoa!!! Does tr1::bind provide the relational operators that boost::bind does? We use these extensively throughout our production code. Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: New libraries should provide forward declarations?

Benoit — 2008-08-21T12:37:39

This is not exactly true. I already use such an approach in my own developments. The idea is to use concepts to make sure that the right member functions are called inside a cpp file and therefore will be compiled and usable everywhere.That would mean pulling in all related implementation details... But only for one compilation unit (created with that purpose in mind). Other compilation units would only have access to template class definitions. For that matter, i personally use the .h extension for template class definitions and .hpp for template class method definitions (but that's only an example of what could be done). Note that i agree that it would also bring a readability benefit to the source code. Benoît _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Daniel James — 2008-08-21T11:33:53

2008/8/21 Gennaro Prota yahoo.com>: Yes, these things have to work both ways. We're in a tricky position because many of our libraries are low level and support a large number of platforms with all kinds of quirks and incompatibilities. The code often ends up complex and it's hard to make small changes without a fairly deep understanding. Many developers do an admirable job at trying to limit the complexity but it's to some extent unavoidable. A lot of boost is just weird voodoo. Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Vladimir Prus — 2008-08-21T11:19:26

On all platforms, including those that are not release platforms? Say somebody commits a revision 1234567 to trunk; if there an easy way to tell if it's OK to merge trunk state, as of revision 1234567 to the release branch? Preferrably, without manually comparing the list of release compilers with the list of compilers used for trunk testing and comparing revision numbers for each? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [extension] Check if basic_type_map is empty

Boris — 2008-08-21T11:15:23

On Thu, 21 Aug 2008 00:05:08 +0200, Jeremy Pack gmail.com> wrote: Thank you! I was rearranging some code when I started to use Andrey's logging library. With empty() I can implement a function loading a shared library and calling types like this: bool init(const std::string &name) { shared_library lib(name); if (!lib.open()) BOOST_LOG(mylogger) << "error ..."; else if (!lib.call(types)) BOOST_LOG(mylogger) << "error ..."; else BOOST_LOG(mylogger) << "no error ..."; return lib.is_open() && !types.empty(); } As you see it was not a very important request. :) Boris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [bigint] Integer data type larger than 64 bits?

Kevin Sopp — 2008-08-21T10:40:52

All of them ;-) boost/mp_math/mp_int.hpp is the file that should be included, it includes all the other headers. It can, but only if you have a 128 bit word type (necessary for intermediate results in the calculations) or if all important calculations were coded in assembler. Then I could take advantage of add with carry instructions etc and handle carries in place. Because I would need direct access to its internal size member. So what you actually need is a fixed precision integer that lives on the stack. mp_int involves memory allocation and algorithms designed for very large integers which is probably overkill. It will be there soon. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [1.37.0] branches/release open for merges

Gennaro Prota — 2008-08-21T10:30:55

Probably more :-) Yes. I don't know about competence. But certainly "dedication"... :-) (just to be sure we're talking about the same thing: I'm referring to 1.34.0; he was so missing, all the time, that in a few occasions I have even been ironic about it ). Yes, getting a release out takes a heroic effort, which Beman (and Rene, I think --sorry if I forget anyone else) has been willing to put in. Others haven't. That's why I said Beman absence was crucial: there is/was no one else with the time and patience to do what he does. And then Beman tried to define a different schema for managing things; isn't that part of his dedication?