Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
"David B. Held" <[EMAIL PROTECTED]> writes:
>> In principle you don't have to promise to delete the unmanaged
>> resource if your constructor throws; it's just your desire to be
>> usable with "new T" that makes it neccessary.
>
> Ok, I think I get it. Whereas, if a policy were to throw, and leak an
> internally allocated count, then the c'tor does not even provide the
> basic guarantee?
Right.
>> In fact, I have been arguing for years that our smart pointers should
>> never have had a public interface which adopts unmanaged resources
>>on construction. Instead, we should write:
>>
>> std::auto_ptr = std::auto_ptr_new(arg1, arg2, arg3);
>>
>> Voila, a managed T straight out of the box.
>
> It might be nice if you assigned it to a variable. ;>
Some people are never satisfied ;>
>> However, the desire to subsume existing smart pointers means you
>>have to support the unsafe "unmanaged adoption interface."
>
> Maybe we can eat our cake and have it too.
If eating the cake means "not having to support unmanaged adoption", I
don't think so ;-)
>> [...]
>> The move proposal says that standard components will require
>> the move construct/assign of their UDT parameters, if any, to be
>> nothrow. In practice that would be needed by any generic
>> components. That's enough to make the move undo-able.
>
> Ok, but that still leaves smart_ptr with a few tricks to pull off. Let's
> look at smart_ptr(std::auto_ptr p) for a minute:
>
> smart_ptr(std::auto_ptr& p)
> : storage(p), ownership(p), checking(), conversion()
> { checking::on_init(p); }
>
> Now, the first that happens is that storage(p) attempts to take
> ownership of p.
p is an auto_ptr&, so how is that ever going to happen?
> For default storage, this is a no-throw operation. Let's say we're
> moving p into a counted pointer. Now ownership has to allocate a
> count, and might throw in the process. If it does, we either have
> to clean up p, or we have to stuff the toothpaste back into the
> tube.
Both highly imprecise notions; I don't know what either means for sure
in this context.
> I see that shared_ptr solves this by violating RAII.
I don't know what this means either. RAII is not something you can
"violate". It's a technique or idiom.
No time to look at the rest of this right now...
--
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: is_base_and_derived question
"Gennaro Prota" <[EMAIL PROTECTED]> wrote > > Well, then I imagine you would prefer the old semantics. Was there > anybody complaining that being not enough? > Yes, I was. A while back, I pointed out to Rani that is_base_and_derived was insufficient to implement is_com_ptr, a trait I needed. In COM programming, every interface inherits from IUnknown, and many COM objects implement multiple interfaces. So is_base_and_derived was almost always ambiguous. I was content to gripe, but Rani actually did something about it. The new behavior of is_base_and_derived is very welcome, IMO. Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> Up to a point. I know MWerks is object-compatible in the
>> single-inheritance case (for the sake of COM and MFC), but not
>> if there's MI. However, they still have MI EBO problem.
>>
>> Further, this is not a Win32-specific problem. Most Unix compilers
>> that aren't GCC-3.x have it as well, AFAICT.
>
> So in your opinion, *ought* the optimally_inherit solution to work
> even on these compilers?
If you don't care about ctors and dtors, it sounds plausible, but
there's no reason in principle that they shouldn't have the same
problems you cite below for VC++. You never know with some of them,
though. Borland is particularly strange about layout.
>> [...]
>> I guess that's OK if you don't care how many ctors and dtors get
>> called. The lifetimes of these temporaries obviously won't mirror
>> that of the smart_ptr. Sounds like a fragile arrangement to me.
>
> I imagine that the temporaries won't get created at all,
Whaaa? A temporary that never gets created?
> since their sole purpose is to verify policy compatibility. In the
> majority of cases, they will simply call an appropriate copy c'tor,
> which will be trivial or generated, because the class has no state.
Maybe you should illustrate what you mean, 'cause I'm lost.
>> If you only inherit from non-empty bases, how is EBO relevant at
>> all?
>
> That's a very good question. Maybe I should call it an "Empty
> Derived Optimization" problem. For some reason, even in this
> configuration, VC++ insists that sizeof(smart_ptr) > 8:
>
> class smart_ptr
> : optimally_inherit<
> optimally_inherit,
> optimally_inherit
> >
> { ... }
Since I can't see what's in the bases nor any of smart_ptr's data
members here, it's hard to know how to interpret sizeof(smart_ptr) > 8
or whether it's even a problem [but I get it below].
> I can prove that optimally_inherit only derives
> from storage, and similarly for ownership with a simple test case.
> So why VC++ thinks it needs to inflate the size of smart_ptr is
> beyond me. But it isn't just smart_ptr. It inflates the size of the top-
> level optimally_inherit, which is inheriting from two non-empty base
> classes. Perhaps we should call it the "Non-emtpy Base MI
> Pessimization" (NoBMIP)?
OK, I get the picture now.
> I assumed it was because it didn't want any of the bases to share an
> address with the derived class, which is analogous to the EBO case.
> But perhaps I misunderstand what is going on, and you can shed some
> light on it for me.
I don't think I can do any better than you. I have the same tools at
my disposal. I'd do a bunch of experiments and look at the resulting
class layouts by checking the size and the relative addresses of
members.
>> [...]
>> > I know that optimally_inherit *does* work under VC++ for some
>> > cases. I just don't know exactly what those cases are, and I don't
>> > really want to spend a week trying to discover it, especially as that
>> > won't help people who are writing custom policies.
>>
>> Why not?
>
> Well, suppose that I discover *some* configuration in which EBO and
> optimally_inherit produce the desired size, but I don't know *why*
> that configuration has the desired result. How is a user to know if
> his custom policy is going to kill EBO again or not, based on the
> working configuration?
You could probably figure out the VC++ algorithm by experimentation,
but that still wouldn't help a user trying to write portable,
efficient code, unless you find a workaround for every other compiler.
--
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: SmartPtr - Exception safety reprise
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> Up to a point. I know MWerks is object-compatible in the
> single-inheritance case (for the sake of COM and MFC), but not
> if there's MI. However, they still have MI EBO problem.
>
> Further, this is not a Win32-specific problem. Most Unix compilers
> that aren't GCC-3.x have it as well, AFAICT.
So in your opinion, *ought* the optimally_inherit solution to work
even on these compilers?
> [...]
> I guess that's OK if you don't care how many ctors and dtors get
> called. The lifetimes of these temporaries obviously won't mirror
> that of the smart_ptr. Sounds like a fragile arrangement to me.
I imagine that the temporaries won't get created at all, since their
sole purpose is to verify policy compatibility. In the majority of
cases, they will simply call an appropriate copy c'tor, which will be
trivial or generated, because the class has no state.
> > Unfortunately, EBO interacts with non-empty bases as well as
> > empty ones, and that is our problem.
>
> If you only inherit from non-empty bases, how is EBO relevant at
> all?
That's a very good question. Maybe I should call it an "Empty
Derived Optimization" problem. For some reason, even in this
configuration, VC++ insists that sizeof(smart_ptr) > 8:
class smart_ptr
: optimally_inherit<
optimally_inherit,
optimally_inherit
>
{ ... }
I can prove that optimally_inherit only derives
from storage, and similarly for ownership with a simple test case.
So why VC++ thinks it needs to inflate the size of smart_ptr is
beyond me. But it isn't just smart_ptr. It inflates the size of the top-
level optimally_inherit, which is inheriting from two non-empty base
classes. Perhaps we should call it the "Non-emtpy Base MI
Pessimization" (NoBMIP)? I assumed it was because it didn't
want any of the bases to share an address with the derived class,
which is analogous to the EBO case. But perhaps I misunderstand
what is going on, and you can shed some light on it for me.
> [...]
> > I know that optimally_inherit *does* work under VC++ for some
> > cases. I just don't know exactly what those cases are, and I don't
> > really want to spend a week trying to discover it, especially as that
> > won't help people who are writing custom policies.
>
> Why not?
Well, suppose that I discover *some* configuration in which EBO and
optimally_inherit produce the desired size, but I don't know *why*
that configuration has the desired result. How is a user to know if his
custom policy is going to kill EBO again or not, based on the working
configuration?
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> What question are you asking? I think all NDAs on the vc7.1 betas >> are expired, so I can just run a test... > > Actually, I wanted someone on the compiler team to give me a set of > circumstances under which EBO is guaranteed to work. If there is no > way to get MI to fit into those circumstances, then we can give up. > >> [...] >> BTW, VC++ is not the only kid on the block, and the same >> argument applies to all the other players. > > Yes, but you seem to imply that other Win32 compilers try to be > object-compatible with VC++ Up to a point. I know MWerks is object-compatible in the single-inheritance case (for the sake of COM and MFC), but not if there's MI. However, they still have MI EBO problem. Further, this is not a Win32-specific problem. Most Unix compilers that aren't GCC-3.x have it as well, AFAICT. > so it seems they should exhibit the same behaviour. > > If there is some way to get the desired optimization, > with any luck, the other compilers will perform it as well. Or maybe > this is wishful thinking? It is in the case of MWerks, anyway. >> [...] >> What is optimally_inherit? Latest round of changes in what? > > Optimally_inherit is a device that is the "dual" of compressed_pair<>. > Andrei suggested it when this issue first came up. Whilst > compressed_pair<> aggregates when a type is non-empty, and > inherits when it's empty, optimally_inherit inherits when the type > is non-empty, and just calls c'tors on temporaries when the type is > empty. This way, empty bases don't actually enter the inheritance > tree. I guess that's OK if you don't care how many ctors and dtors get called. The lifetimes of these temporaries obviously won't mirror that of the smart_ptr. Sounds like a fragile arrangement to me. > Unfortunately, EBO interacts with non-empty bases as well as empty > ones, and that is our problem. If you only inherit from non-empty bases, how is EBO relevant at all? > The "latest round of changes" is the set of changes that moves > cleanup from named procedures (destroy(), release(), etc.) to d'tors. > For this reason, I suspected that non-trivial user-defined d'tors were > causing VC++ to drop EBO. But commenting out the d'tors just to > check the size did not restore EBO. So now I would like a VC++ > compiler team member (preferably the one(s) who wrote the EBO > code) to tell me when EBO works, and when it doesn't, or as much > about that as possible. The optimally_inherit trick works just fine > on BCB, and gcc didn't need it to begin with (that big stud of a > compiler!). If we can get VC++ and VC++ wannabes to invoke > EBO again, we can at least cover a good amount of the market, no? Yes. > I know that optimally_inherit *does* work under VC++ for some cases. > I just don't know exactly what those cases are, and I don't really > want to spend a week trying to discover it, especially as that won't > help people who are writing custom policies. Why not? -- 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: SmartPtr - Exception safety reprise
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > What question are you asking? I think all NDAs on the vc7.1 betas > are expired, so I can just run a test... Actually, I wanted someone on the compiler team to give me a set of circumstances under which EBO is guaranteed to work. If there is no way to get MI to fit into those circumstances, then we can give up. > [...] > BTW, VC++ is not the only kid on the block, and the same > argument applies to all the other players. Yes, but you seem to imply that other Win32 compilers try to be object-compatible with VC++, so it seems they should exhibit the same behaviour. If there is some way to get the desired optimization, with any luck, the other compilers will perform it as well. Or maybe this is wishful thinking? > [...] > What is optimally_inherit? Latest round of changes in what? Optimally_inherit is a device that is the "dual" of compressed_pair<>. Andrei suggested it when this issue first came up. Whilst compressed_pair<> aggregates when a type is non-empty, and inherits when it's empty, optimally_inherit inherits when the type is non-empty, and just calls c'tors on temporaries when the type is empty. This way, empty bases don't actually enter the inheritance tree. Unfortunately, EBO interacts with non-empty bases as well as empty ones, and that is our problem. The "latest round of changes" is the set of changes that moves cleanup from named procedures (destroy(), release(), etc.) to d'tors. For this reason, I suspected that non-trivial user-defined d'tors were causing VC++ to drop EBO. But commenting out the d'tors just to check the size did not restore EBO. So now I would like a VC++ compiler team member (preferably the one(s) who wrote the EBO code) to tell me when EBO works, and when it doesn't, or as much about that as possible. The optimally_inherit trick works just fine on BCB, and gcc didn't need it to begin with (that big stud of a compiler!). If we can get VC++ and VC++ wannabes to invoke EBO again, we can at least cover a good amount of the market, no? I know that optimally_inherit *does* work under VC++ for some cases. I just don't know exactly what those cases are, and I don't really want to spend a week trying to discover it, especially as that won't help people who are writing custom policies. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote: At 12:39 PM 2/1/2003, Matthias Troyer wrote: >< cat regress.log | $process_jam_log >--- > > cat regress.log | $process_jam_log $boost_root >... >Finally, I wonder why I need the sixth change. How does this work on >other platforms? Is there an easier fix? I can answer that one. If process_jam_log is given no argument, it assumes it is being run from some directory within the boost directory tree, and starts recursing upward looking for boost-root. (It assumes any directory with a sub-directory named "libs" is the boost-root.) That mechanism is probably at play in the script. Specifying a directory argument is particularly useful if ALL_LOCATE_TARGET is being used to place the test targets someplace outside of the boost-root tree, which is a good idea. Since I run it from within the boost directory tree, it probably fails to find it automatically on the Cray. Is that a bug I should investigate further? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> C) Make sure the first base class of smart_ptr is the one that >> manages destruction of its resources: > I was actually thinking in this direction somewhat. Then you're getting the hang of this EH stuff; congratulations! > I did notice that it really is the smart_ptr d'tor that really knows > how to properly clean stuff up, and it should probably be the one to > do so. But coordinating cleanup in the smart_ptr dtor was causing the problem you cited in the first place! In my version it's the ptr_manager base class that coordinates the cleanup by encapsulating ownership and storage. -Dave -- 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] Re: SmartPtr - Exception safety reprise
"David B. Held" <[EMAIL PROTECTED]> writes: > Well, I want to at least give the VC++ guys a few days to see if > they say anything. I posted a question on a M$ newsgroup. I > think I did the first time around, too, and they didn't. It would be > really cool if, say, Jason Shirk offered some insight, or at least > knocked some skulls so we got *some* kind of answer, even if > it's "there's no way in heck we will give out that kind of > information". What question are you asking? I think all NDAs on the vc7.1 betas are expired, so I can just run a test... However, you obviously missed my point: there _is_ no way in heck they're going to change the object layout, thus making vc7.1 object code incompatible with vc7 object code. Objects with multiple empty bases have to have the same size in both versions and their members have to live at the same offsets. BTW, VC++ is not the only kid on the block, and the same argument applies to all the other players. > At least then I could give up hope, and we could fully enter the > tedious debate over alternatives. But there must be *someone* on > the VC++ compiler team that wrote the EBO code, and if it were me, > I'd have enough pride to at least say when I know that it *does* > work (and it does work for some MI...optimally_inherit was doing its > job until the latest round of changes). What is optimally_inherit? Latest round of changes in what? -- 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: SmartPtr - Exception safety reprise
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> C) Make sure the first base class of smart_ptr is the one that
> manages destruction of its resources:
>
> template
> struct ptr_manager
> : Storage, Ownership
> {
> ptr_manager(ptr_manager const& p) : Storage(p), Ownership(p) {}
>
> ~ptr_manager()
> {
> if (!this->Ownership::release(get_impl(*this)))
> {
> this->Storage::release();
> }
> }
> };
>
>smart_ptr::smart_ptr(smart_ptr const& rhs)
> : ptr_manager(rhs), checking(rhs), conversion(rhs)
>{ checking::on_init(p); }
I was actually thinking in this direction somewhat. I did notice that it
really is the smart_ptr d'tor that really knows how to properly clean
stuff up, and it should probably be the one to do so. This might be
the way to go.
> [...]
> I think that whatever orthogonal concepts are being represented
> by ownership and storage here (and I'm really not sure I see a
> clear separation), they must be sub-concepts of what is normally
> referred to as ownership. You can see that from the fact that you
> need a sub-object to group them together to handle resource
> lifetime correctly. I would explore/discuss the implications of not
> separating ownership and storage to see whether it's buying you
> more than it's costing.
There are several cases where it's clear that storage and ownership
aren't the same thing. First, is scalar_storage vs. array_storage.
Second, is pointer vs. other resource. Pointers to arrays benefit
from all of the ownership strategies provided by SmartPtr that
pointers to objects enjoy. A smart resource can certainly make
use of ref-counting, deep copy, no-copy, and move semantics. I
think it's clear that with respect to these ideas, storage and ownership
are indeed orthogonal. Merging them would evoke a combinatorial
explosion of the nature hinted at by scoped_ptr, shared_ptr,
scoped_array, shared_array, (scoped_resource, shared_resource,
deep_ptr, deep_array, deep_resource, intrustive_ptr,
intrusive_resource, com_ptr, com_resource, etc.).
It's unfortunate that they must interact, but I do believe that they are
orthogonal in principle. However, your intermediate class might be
the most appropriate decomposition. I'm leaning towards that
pending further insight/analysis.
> BTW, I don't want to beat this to death, but addressing the issue
> of most compilers not doing the EBO for anything other than the
> first base class has a huge bearing on all of this,
Well, I want to at least give the VC++ guys a few days to see if
they say anything. I posted a question on a M$ newsgroup. I
think I did the first time around, too, and they didn't. It would be
really cool if, say, Jason Shirk offered some insight, or at least
knocked some skulls so we got *some* kind of answer, even if
it's "there's no way in heck we will give out that kind of
information". At least then I could give up hope, and we could
fully enter the tedious debate over alternatives. But there must
be *someone* on the VC++ compiler team that wrote the EBO
code, and if it were me, I'd have enough pride to at least say
when I know that it *does* work (and it does work for some
MI...optimally_inherit was doing its job until the latest round of
changes). Bueller? Bueller? Bueller?
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard LibraryTechnicalReport
At 11:41 AM 2/1/2003, Alisdair Meredith wrote: >Beman Dawes wrote: > >> See http://www.boost.org/more/cpp_committee_meetings.html. While the >> general public isn't invited to committee meetings, Boost "technical >> experts" are welcome. > >So how would I qualify myself as a "Boost technical expert"? Just participate in discussions, nothing special. Jeff Garland's suggestions were good ones; lend a helping hand with any of those projects. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
At 12:39 PM 2/1/2003, Matthias Troyer wrote: >< cat regress.log | $process_jam_log >--- > > cat regress.log | $process_jam_log $boost_root >... >Finally, I wonder why I need the sixth change. How does this work on >other platforms? Is there an easier fix? I can answer that one. If process_jam_log is given no argument, it assumes it is being run from some directory within the boost directory tree, and starts recursing upward looking for boost-root. (It assumes any directory with a sub-directory named "libs" is the boost-root.) That mechanism is probably at play in the script. Specifying a directory argument is particularly useful if ALL_LOCATE_TARGET is being used to place the test targets someplace outside of the boost-root tree, which is a good idea. HTH, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
"Jonathan Wang" <[EMAIL PROTECTED]> writes:
> Thanks for the url of use of BOOST_MPL_AUX_LAMBDA_SUPPORT.
> Why not more in the documetation :-)
Aleksey is working on that as I type.
> What do you mean by "a single framework could be used to handle both approaches"?
I mean a library which would allow you to extract optional types
parameters based on either their wrapper templates ("Color_is<...>")
or on a predicate (e.g. pick the one for which is_class::value is
true).
> Mixing NTPs and ordinary ones is quite interesting. What I present here is
>
> mpl::vector, Color_is, ...>
>
> and we can use
>
> mpl::vector >
>
> to update it. The users can decide whether to convert glx to
> Model_is implicitly is allowed. And here it're more like a type
> property map, but properties is presented as templates rather than
> types.
That too.
--
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@lists.boost.org
Hi Julius,
you wrote:
> now that sparse matrix_row's works with Joerg's latest CVS upload (thanks
> Joerg), a const& parameter that used to work with 1_29_0 doesn't anymore:
Ouch ;-(
> using namespace boost::numeric;
> typedef ublas::matrix TM;
>
> double InnerProdConst( const TM& A, const ublas::vector& x )
> {
> return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ), x );
> }
>
> VC++.NET complains that some internal conversion loses qualifiers,
> This does compile with a non const matrix reference parameter, the same is
> true if I use a sparse_matrix or a compressed_matrix. I didn't try the
> other matrix types, but since this breaks with three matrix types, it
looks
> like it has to do with matrix_row itself.
The following code compiles successfully with GCC 3.2.1:
#include
using namespace boost::numeric;
typedef ublas::matrix TM;
double InnerProdConst( const TM& A, const ublas::vector& x )
{
return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ), x );
}
int main()
{
ublas::matrix< double > A( 3, 3 );
ublas::vector< double > x( 3 );
std::cout << InnerProdConst( A, x ) << std::endl;
}
I'll try to check this with MSVC 6.0 tomorrow.
> I think this should work with const&'s since inner_prod is non mutating.
> I'd like to keep the const&'s.
>
> Joerg: You suggested using compressed_matrix instead of sparse_matrix in
> your recent response to my matrix_row access problem. I couldn't find much
> in the documentation about the pros and cons of either type. Can you give
> me hint where to look for more information? Thanks.
Alexei Novakov's benchmarks show that Fortran like CRS/CCS schemes are more
efficient in most cases.
Best,
Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived explanation?
>From: "Rani Sharoni" <[EMAIL PROTECTED]> > "John Maddock" <[EMAIL PROTECTED]> wrote in message > 012801c2c9eb$d07c4da0$b2e5193e@1016031671">news:012801c2c9eb$d07c4da0$b2e5193e@1016031671... > > OK the new version of is_base_and_derived is checked in, along with > stricter > > test cases, can someone who understands the implementation (I'm absolutely > > sure that I don't !), please provide an explanation to add to the header? > > > > BTW I have looked at Terje's explanation, but the subtle changes to the > > Rani's implementation make in no longer quite applicable (although I may > > be missing something). > > Terje's fine explanation holds (just change reference to pointer). > I think that link to the original c.l.c++.m posting might be helpful > especially because it contains a link to an explanation by probably the most > authorized person in C++ overloading - Steve Adamczyk. > > The c.l.c++.m posting - > http://groups.google.com/groups?selm=df893da6.0301280859.522081f7%40posting. google.com Thanks for the compliment, but the explanation was written in a rather informal way. However, it could be used as a basis for understanding how it works, to then write an explanation for it. Also, I used an example of multiple bases in the explanation, while the formal explanation should probably be more general. I've looked at the CVS version, and I see that it's like Rani says - the explanation still holds, just changing reference to pointer. I also included the above link in the explanation. However, as the link to Daveeds posting from that one uses the link http://tinyurl.com/502f, this might not be that lasting, so it could be good to include the original link that this one points to, as well. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: In-memory databases
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> writes: > OK. > How do I access the sandbox and samples? Look for the sandbox link on the boost homepage. -- 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: Re: In-memory databases
OK. How do I access the sandbox and samples? "David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Arkadiy Vertleyb" <[EMAIL PROTECTED]> writes: > > > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > >> > See http://www.boost.org/libs/utility/permutation_iterator.htm > > > > It looks like we may benefit from this when sorting/indexing. However, when > > I said that we adapt two iterators rather than one, I meant two iterators > > from two different containers. Like intersection iterator is based on the > > iterators of both intersection arguments. > > Iterator Adaptor has a lot of smart defaults derived from the Base > (underlying) type when it is an iterator. You may or may not be able > to take advantage of many of these, depending on the nature of your > iterators. The other big benefit of Iterator Adaptor is that it > implements the iterator concepts correctly, which is nontrivial. > > In the sandbox code these aspects are factored into iterator_facade > and iterator_adaptor; you might just want to use iterator_facade. > > -- >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 > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: In-memory databases
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > See http://www.boost.org/libs/utility/permutation_iterator.htm > > It looks like we may benefit from this when sorting/indexing. However, when > I said that we adapt two iterators rather than one, I meant two iterators > from two different containers. Like intersection iterator is based on the > iterators of both intersection arguments. Iterator Adaptor has a lot of smart defaults derived from the Base (underlying) type when it is an iterator. You may or may not be able to take advantage of many of these, depending on the nature of your iterators. The other big benefit of Iterator Adaptor is that it implements the iterator concepts correctly, which is nontrivial. In the sandbox code these aspects are factored into iterator_facade and iterator_adaptor; you might just want to use iterator_facade. -- 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: In-memory databases
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > See http://www.boost.org/libs/utility/permutation_iterator.htm It looks like we may benefit from this when sorting/indexing. However, when I said that we adapt two iterators rather than one, I meant two iterators from two different containers. Like intersection iterator is based on the iterators of both intersection arguments. Arkadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived explanation?
"John Maddock" <[EMAIL PROTECTED]> wrote in message 012801c2c9eb$d07c4da0$b2e5193e@1016031671">news:012801c2c9eb$d07c4da0$b2e5193e@1016031671... > OK the new version of is_base_and_derived is checked in, along with stricter > test cases, can someone who understands the implementation (I'm absolutely > sure that I don't !), please provide an explanation to add to the header? > > BTW I have looked at Terje's explanation, but the subtle changes to the > Rani's implementation make in no longer quite applicable (although I may be > missing something). Terje's fine explanation holds (just change reference to pointer). I think that link to the original c.l.c++.m posting might be helpful especially because it contains a link to an explanation by probably the most authorized person in C++ overloading - Steve Adamczyk. The c.l.c++.m posting - http://groups.google.com/groups?selm=df893da6.0301280859.522081f7%40posting. google.com Cheers, Rani ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: In-memory databases
David Abrahams <[EMAIL PROTECTED]> writes: > "Arkadiy Vertleyb" <[EMAIL PROTECTED]> writes: > >> "David Abrahams" <[EMAIL PROTECTED]> wrote in message >> We did consider iterator adaptors when we started. The main problem is that >> we have more iterators based on two iterators, rather than on one -- I don't >> know whether we can benefit from iterator adaptors in this case. Can we? > > Usually. See http://www.boost.org/libs/utility/permutation_iterator.htm HTH, -- 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] Re: Re: In-memory databases
David Abrahams <[EMAIL PROTECTED]> writes: > See http://www.boost.org/libs/utility/permutation_iterator.htm One other thing: we're working on a redesign which is in the boost sandbox under boost/iterator/ and libs/iterator. It's much easier to use in many ways, so you might consider planning for that. No documentation yet, but there are plenty of examples. -Dave -- 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] Re: Deadline for the Standard LibraryTechnicalReport
>Currently I'm investigating format, Spirit and threads, but if any-one >submitting libraries wants another pair of eyes looking over the >submission just ask. [I've been holding back comments on smart- pointers >as it has been quite busy without my help ] Here are a couple of library efforts that could use a boost ;-) http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Documentation_Format A smaller library that is getting close to submission is the string algorithms. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?STLAlgorithmExtensions/StringAlgorithms You can find source for all of these in the sandbox. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: In-memory databases
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > > We did consider iterator adaptors when we started. The main problem is that > > we have more iterators based on two iterators, rather than on one -- I don't > > know whether we can benefit from iterator adaptors in this case. Can we? > > Usually. In this case we will re-evaluate this issue. Arkadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: In-memory databases
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > We did consider iterator adaptors when we started. The main problem is that > we have more iterators based on two iterators, rather than on one -- I don't > know whether we can benefit from iterator adaptors in this case. Can we? Usually. -- 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: In-memory databases
We did consider serialization. You can take a look at test/persist.cpp and persist.h. They implement serialization of a tuple. With the help of this it's quite easy to serialize any relation (whether table or operator). This can be used either to implement persistable tables, or for client-server data transfer. There is yet another aspect. In our library a table is separated from its implementation (although right now it may be done not in the best possible way). Our current implementation is based on the sorted std::vector. Ideally, there should be multiple implementations, memory and disk based (talking about persistence). Such differently implemented tables should be able to join, etc. Although, theoretically, table implementations are out of scope of the library, we'll work in this direction if people consider this important. However, our resources are quite limited. Anybody interested is invited to cooperate. Arkadiy "David B. Held" <[EMAIL PROTECTED]> wrote in message b1h2ej$ibe$[EMAIL PROTECTED]">news:b1h2ej$ibe$[EMAIL PROTECTED]... > "Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message > b1grsi$qh2$[EMAIL PROTECTED]">news:b1grsi$qh2$[EMAIL PROTECTED]... > > Yes, we are currently working on such a database. > > [...] > > After looking at the documentation, it looks like you have left out > serialization/persistence completely. That's ok, if that's the aim of your > project. Did you plan to add that later? It would be nice to see some > progress on the serialization/persistence lib. I think these could be > put together into a pretty powerful library. I think the harder part is > writing the query engine, which it looks like you already have done > (more or less). > > Dave > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
On Saturday, February 1, 2003, at 07:07 PM, David Abrahams wrote: Matthias Troyer <[EMAIL PROTECTED]> writes: First the (maybe stupid) question: how can I disable the building of shared libraries when using bjam? Shared libraries do not seem to exist on the vector-Crays and I would like to disable them, instead of getting build failures. Not stupid at all; currently Boost.Build doesn't have a way to deal with target types that aren't supported at all on a given platform. We'll have to see if we can find a way to handle that. For now these parts just fail and wast some time during the build process, but that's not an urgent issue, since we can just let those targets fail. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] SmartPtr - Exception safety reprise
"David B. Held" <[EMAIL PROTECTED]> writes:
> I started a new thread because the old one was getting hard to
> follow on my newsreader from the excessive nesting. I realized
> there is yet another problem with my scheme (which should come
> as no suprise by now). This time, the problem is the copy c'tor.
> Here's a recap:
>
> storage::storage(storage const& rhs)
> : pointee_(rhs.pointee_)
> { }
>
> storage::~storage()
> { checked_delete(pointee_); }
>
> void storage::release()
> { pointee_ = default_value(); }
>
> ref_counted::ref_counted(ref_counted const& rhs)
> : count_(rhs.count_)
> { }
>
> ref_counted::~ref_counted()
> { delete count_; }
>
> bool ref_counted::release(P const& p)
> {
> if (!--*count_) return true;
> count_ = 0; return false;
> }
>
> smart_ptr::smart_ptr(smart_ptr const& rhs)
> : storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
> { checking::on_init(p); }
>
> smart_ptr::~smart_ptr()
> {
> if (!ownership::release(get_impl(*this)))
> {
> storage::release();
> }
> }
>
> The problem is that while ref_counted indeed cleans up its count in
> the face of later exceptions, it may do so prematurely. For instance,
> if checking(rhs) were to throw, ~smart_ptr() does not get a chance
> to call ownership::release(), which prevents ownership from deleting
> the count. Similarly, if, for some reason, ownership(rhs) were to
> throw, storage might prematurely free the resource. The two most
> viable solutions I can think of are:
>
> A) add scope guards to make sure the right thing is done no matter
> who throws
>
> B) require that copying be no-throw
C) Make sure the first base class of smart_ptr is the one that
manages destruction of its resources:
template
struct ptr_manager
: Storage, Ownership
{
ptr_manager(ptr_manager const& p) : Storage(p), Ownership(p) {}
~ptr_manager()
{
if (!this->Ownership::release(get_impl(*this)))
{
this->Storage::release();
}
}
};
smart_ptr::smart_ptr(smart_ptr const& rhs)
: ptr_manager(rhs), checking(rhs), conversion(rhs)
{ checking::on_init(p); }
This is just more of the same RAII principles we've been discussing at
work.
I think that whatever orthogonal concepts are being represented by
ownership and storage here (and I'm really not sure I see a clear
separation), they must be sub-concepts of what is normally referred to
as ownership. You can see that from the fact that you need a
sub-object to group them together to handle resource lifetime
correctly. I would explore/discuss the implications of not separating
ownership and storage to see whether it's buying you more than it's
costing.
BTW, I don't want to beat this to death, but addressing the issue of
most compilers not doing the EBO for anything other than the first
base class has a huge bearing on all of this, because solving it means
you have to change the base class organization. For me at least, one
of the primary reasons to use a policy-based smart pointer would be to
get the optimizations it can offer for really time-critical code. In
fact, at the moment that's the *only* reason I can imagine wanting
something other than boost::shared_ptr<>. If shared_ptr doesn't have
optimal footprint on most compilers I would be reluctant to use it
where efficiency matters most, and thus it would become useless to me.
I don't know about other people.
--
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: In-memory databases
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At a first glance, I have two remarks: > > The first is trivial: your #include guards are all symbols reserved to > the C++ implementation. No double underscores, please! They're also > not very unique. I use my initials and the date to help avoid > collisions: > > Instead of __JOIN__, I'd use something like JOIN_HPP_DWA20030128. This can be easily changed once we agree on which rule to use. Yours is fine with me. > The second is nontrivial: I think you could probably simplify your > code a lot and increase portability at the same time by making better > use of Boost components, primarily MPL and iterator adaptors. In general, I do agree. As far as MPL is concerned, when we started, it was not yet accepted. All our meta-programming stuff is located in a few files, so it should not be difficult to change if we decide to do so. On the other hand, all our template meta-programming is rather trivial operations on the type list, so I don't think they add too much complexity. We did consider iterator adaptors when we started. The main problem is that we have more iterators based on two iterators, rather than on one -- I don't know whether we can benefit from iterator adaptors in this case. Can we? Arkadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
Matthias Troyer <[EMAIL PROTECTED]> writes: > Dear Boosters, > > Since we got to work jam on the Cray, found an > optimizer bug when compiling regex with -O3 that we > will report to Cray and got regex to compile at -O2, I > am now running the regression tests. > > While they are running I want to ask a question about > building and post a patch/question about running the > rgeression tests. > > First the (maybe stupid) question: how can I disable > the building of shared libraries when using bjam? > Shared libraries do not seem to exist on the > vector-Crays and I would like to disable them, instead > of getting build failures. Not stupid at all; currently Boost.Build doesn't have a way to deal with target types that aren't supported at all on a given platform. We'll have to see if we can find a way to handle that. -- 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: In-memory databases
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message b1grsi$qh2$[EMAIL PROTECTED]">news:b1grsi$qh2$[EMAIL PROTECTED]... > Yes, we are currently working on such a database. > [...] After looking at the documentation, it looks like you have left out serialization/persistence completely. That's ok, if that's the aim of your project. Did you plan to add that later? It would be nice to see some progress on the serialization/persistence lib. I think these could be put together into a pretty powerful library. I think the harder part is writing the query engine, which it looks like you already have done (more or less). Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] SmartPtr - Exception safety reprise
I started a new thread because the old one was getting hard to
follow on my newsreader from the excessive nesting. I realized
there is yet another problem with my scheme (which should come
as no suprise by now). This time, the problem is the copy c'tor.
Here's a recap:
storage::storage(storage const& rhs)
: pointee_(rhs.pointee_)
{ }
storage::~storage()
{ checked_delete(pointee_); }
void storage::release()
{ pointee_ = default_value(); }
ref_counted::ref_counted(ref_counted const& rhs)
: count_(rhs.count_)
{ }
ref_counted::~ref_counted()
{ delete count_; }
bool ref_counted::release(P const& p)
{
if (!--*count_) return true;
count_ = 0; return false;
}
smart_ptr::smart_ptr(smart_ptr const& rhs)
: storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
{ checking::on_init(p); }
smart_ptr::~smart_ptr()
{
if (!ownership::release(get_impl(*this)))
{
storage::release();
}
}
The problem is that while ref_counted indeed cleans up its count in
the face of later exceptions, it may do so prematurely. For instance,
if checking(rhs) were to throw, ~smart_ptr() does not get a chance
to call ownership::release(), which prevents ownership from deleting
the count. Similarly, if, for some reason, ownership(rhs) were to
throw, storage might prematurely free the resource. The two most
viable solutions I can think of are:
A) add scope guards to make sure the right thing is done no matter
who throws
B) require that copying be no-throw
The problem with A) is that it imposes a performance penalty on
copying, which might be seen as undesirable. The problem with B)
is that deep_copy would probably like to throw. I guess there is
a third option:
C) require no-throw semantics only for certain policy configurations
Which is, of course, what I've already suggested for the P const& p
c'tors. Comments?
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regression tests on Cray
Dear Boosters, Since we got to work jam on the Cray, found an optimizer bug when compiling regex with -O3 that we will report to Cray and got regex to compile at -O2, I am now running the regression tests. While they are running I want to ask a question about building and post a patch/question about running the rgeression tests. First the (maybe stupid) question: how can I disable the building of shared libraries when using bjam? Shared libraries do not seem to exist on the vector-Crays and I would like to disable them, instead of getting build failures. Next, the changes I had to make to boost/tools/regression/run_tests.sh. Besides the obvious toolset and path changes (the first three), I had to make three more changes: diff -r1.3 run_tests.sh 18c18 < boost_root=$HOME/CVSROOTs/Boost/boost_regression --- > boost_root=$HOME/boost 35c35 < test_tools=gcc --- > test_tools=cray 42c42 < toolset=gcc --- > toolset=cray 96c96 < if test $cvs_update == yes ; then --- > if test $cvs_update = yes ; then 113c113 < LOCATE_TARGET=bin sh ./build.sh --- > LOCATE_TARGET=bin sh ./build.sh cc 150c150 < cat regress.log | $process_jam_log --- > cat regress.log | $process_jam_log $boost_root The fourth change: test $cvs_update == yes ---> test $cvs_update = yes seems to be needed for all platform, although the GNU version of test actually accepts == in addition to = The fifth change is needed, to use the cc toolset instead of gcc. Is there an easy way to specify that without changing the shell script? Finally, I wonder why I need the sixth change. How does this work on other platforms? Is there an easier fix? Best regards, Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: In-memory databases
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message b1grsi$qh2$[EMAIL PROTECTED]">news:b1grsi$qh2$[EMAIL PROTECTED]... > Yes, we are currently working on such a database. Ok, I was of the impression that your library was some kind of caching interface or template interface to external disk-based databases. My apologies. > [...] > Here is the link: > > http://groups.yahoo.com/group/boost/files/tables.zip > > We look forward to any feedback. Specifically, since the library is > very young, we would like to know if the set of features it provides > is reasonably complete. I'll make more comments once I have looked at it, but I'm interested in some of the properties I've seen advertised for commercial and open source databases, such as disk checkpointing, transaction journalling, and other features that would allow it to be not merely an in-memory database, but an actual replacement for a conventional disk-based database. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: In-memory databases
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> writes: > Yes, we are currently working on such a database. Our library uses > template meta-programming to enable creation of relational tables capable of > storing ANY type of data in their fields. The only requirements to the type > is the same as an STL container would impose. We also provide a full set of > relational algebra operators on these tables. We also support range queries > based on the sort order, and indexing to control this sort order. > > At this point the library can be used with either MSVC6 or g++. > > Here is the link: > > http://groups.yahoo.com/group/boost/files/tables.zip > > We look forward to any feedback. At a first glance, I have two remarks: The first is trivial: your #include guards are all symbols reserved to the C++ implementation. No double underscores, please! They're also not very unique. I use my initials and the date to help avoid collisions: Instead of __JOIN__, I'd use something like JOIN_HPP_DWA20030128. The second is nontrivial: I think you could probably simplify your code a lot and increase portability at the same time by making better use of Boost components, primarily MPL and iterator adaptors. -- 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: Deadline for the Standard LibraryTechnicalReport
Beman Dawes wrote: > See http://www.boost.org/more/cpp_committee_meetings.html. While the > general public isn't invited to committee meetings, Boost "technical > experts" are welcome. So how would I qualify myself as a "Boost technical expert"? I am hopefully past the 'hump' at work now, and so can spare some long-promised attention for boost-related matters. Currently I'm investigating format, Spirit and threads, but if any-one submitting libraries wants another pair of eyes looking over the submission just ask. [I've been holding back comments on smart-pointers as it has been quite busy without my help ] -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: In-memory databases
Yes, we are currently working on such a database. Our library uses template meta-programming to enable creation of relational tables capable of storing ANY type of data in their fields. The only requirements to the type is the same as an STL container would impose. We also provide a full set of relational algebra operators on these tables. We also support range queries based on the sort order, and indexing to control this sort order. At this point the library can be used with either MSVC6 or g++. Here is the link: http://groups.yahoo.com/group/boost/files/tables.zip We look forward to any feedback. Specifically, since the library is very young, we would like to know if the set of features it provides is reasonably complete. Best regards, Arkadiy "David B. Held" <[EMAIL PROTECTED]> wrote in message b1evg6$iuo$[EMAIL PROTECTED]">news:b1evg6$iuo$[EMAIL PROTECTED]... > I've seen some talk of fully in-memory databases, and have a few > questions: > > 1) Does anyone have any experience with them? > > 2) Would people use them if there were a nice library available? > > It seems that such a library could benefit from the serialization/ > persistence library. A reference for a Java database is here: > > http://www.prevayler.org/wiki.jsp?topic=ObjectPrevalenceSkepticalFAQ > > The list of C++ databases seems pretty small, judging by Google. > > Maybe such a thing is too ambitious to be a Boost library? > > Dave > > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [regex] Linker errors with MSVC
Hi all,
I get a bunch of linker errors while compiling the following testcase
with VC6.5/VC7.1 (current Boost CVS):
test_regex.cpp:
#include
#define BOOST_REGEX_NO_LIB
#define BOOST_REGEX_STATIC_LINK
#include "boost/regex.hpp"
#include "boost/regex/src.cpp"
int main()
{
boost::reg_expression rxstr;
char const *pteststr = "anyregexp";
rxstr = std::string("anyregexp");
boost::match_results what;
boost::regex_search(pteststr, &pteststr[9], what, rxstr,
boost::match_default);
return 0;
}
Command line: cl -I$(BOOST_ROOT) -GX test_regex.cpp
Note: the regex library isn't given to the compiler!
At least one other compiler (I tried ICL7.0) compiles and links this
without any problems.
Any clues?
Regards Hartmut
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
On Saturday, February 1, 2003, at 04:54 AM, Jonathan Wang wrote: Howard Hinnant <[EMAIL PROTECTED]> writes: I've also looked at ntp implementation similar to this (but used Loki type lists), and agree that this is a neat way to go. Essentially you just stick the defaults onto the end of the type list. Then if the user specifies anything, either by a default tag, a named parameter, or a positional parameter, you prepend it to the type list. Then the extraction routine simply searches the type list for the first appropriate parameter. Could you please tell me where to find the implmentation using Loki? I'm rather interested in it. Sure. It is just a demo. I was exploring putting ntp into the hash containers. Here it is: http://home.twcny.rr.com/hinnant/cpp_extensions/hash_ntp_demo.cpp -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
boost@lists.boost.org
Hi Joerg and everybody,
now that sparse matrix_row's works with Joerg's latest CVS upload (thanks
Joerg), a const& parameter that used to work with 1_29_0 doesn't anymore:
using namespace boost::numeric;
typedef ublas::matrix TM;
double InnerProdConst( const TM& A, const ublas::vector& x )
{
return ublas::inner_prod( ublas::matrix_row< const TM >( A, 2 ), x );
}
VC++.NET complains that some internal conversion loses qualifiers,
This does compile with a non const matrix reference parameter, the same is
true if I use a sparse_matrix or a compressed_matrix. I didn't try the
other matrix types, but since this breaks with three matrix types, it looks
like it has to do with matrix_row itself.
I think this should work with const&'s since inner_prod is non mutating.
I'd like to keep the const&'s.
Joerg: You suggested using compressed_matrix instead of sparse_matrix in
your recent response to my matrix_row access problem. I couldn't find much
in the documentation about the pros and cons of either type. Can you give
me hint where to look for more information? Thanks.
Julius
Julius Muschaweck
_
OEC AG
Paul-Gerhardt-Allee 42
81245 Muenchen, Germany
Phone: +49 89 820050-30
Fax: +49 89 820050-41
e-mail:<[EMAIL PROTECTED]>
Internet: www.oec.net
__
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_base_and_derived explanation?
OK the new version of is_base_and_derived is checked in, along with stricter test cases, can someone who understands the implementation (I'm absolutely sure that I don't !), please provide an explanation to add to the header? BTW I have looked at Terje's explanation, but the subtle changes to the Reni's implementation make in no longer quite applicable (although I may be missing something). Many thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
David Abrahams <[EMAIL PROTECTED]> writes: >That's how my "defaults by type properties" thing works as well. I >wonder if a single framework could be used to handle both approaches? Thanks for the url of use of BOOST_MPL_AUX_LAMBDA_SUPPORT. Why not more in the documetation :-) What do you mean by "a single framework could be used to handle both approaches"? Mixing NTPs and ordinary ones is quite interesting. What I present here is mpl::vector, Color_is, ...> and we can use mpl::vector > to update it. The users can decide whether to convert glx to Model_is implicitly is allowed. And here it're more like a type property map, but properties is presented as templates rather than types. = = = = = = = = = = = = = = = = = = = = Regards, Jonathan Wang [EMAIL PROTECTED] 2003-02-01 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
Howard Hinnant <[EMAIL PROTECTED]> writes: >I've also looked at ntp implementation similar to this (but used Loki >type lists), and agree that this is a neat way to go. Essentially you >just stick the defaults onto the end of the type list. Then if the >user specifies anything, either by a default tag, a named parameter, or >a positional parameter, you prepend it to the type list. Then the >extraction routine simply searches the type list for the first >appropriate parameter. Could you please tell me where to find the implmentation using Loki? I'm rather interested in it. Another implementation using nested types, could be found here: http://www.vandevoorde.com/Daveed/News/Archives/10.html#10. = = = = = = = = = = = = = = = = = = = = Regards, Jonathan Wang [EMAIL PROTECTED] 2003-02-01 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
