[boost] Re: Serialization to relational table
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message arecso$9uf$[EMAIL PROTECTED]">news:arecso$9uf$[EMAIL PROTECTED]... > Bohdan, > > If I understand correctly you have some way to split an object into fields. > After you do it, what are your fields, strings? No. Field type is also defineable i.e. int/double/char ... > If so, this is good enough > for putting an object in the grid, but we actually try to achieve different > goals. Yep. You confirmed my first-look thoughts. > We are implementing relational algebra -- joins, projections, etc. With run-time relational libray you also can do joins, projections .. but without compile-time type safety. > on relational tables that look like STL containers, and can have columns of > arbitrary (built-in or user-defined) types. Templates allow us to achieve > this in a typesafe manner. I was thinking about some simple variant of rtl::table with predefined run-time tuple. In this case you can define structure of this tuple during run-time -> define schema of whole table. But i'm still not expert in rtl so i can be wrong. > You are right, we can't dynamically define table schema, this is the price > for type safety. > > Having said that, I am not sure that RTL is a suitable tool for XML > serialization or any serialization at all (I maybe wrong, though). In fact > RTL itself needs to collaborate with a serialization library. We think > persistence and relational algebra are ortogonal things that are often put > together because of RDBMS. Since RTL was mentioned in this context, I > thought I needed to provide certain clarifications. Dynamic variant of rtl theoretically can avoid only in-memory limitations. You can inherit from base class (table,index,database,record, nested_table ...) and supply factory for your platform. Than you can have same interface for in_memory relational tables and for serious relational database table. Most probably you are right: rtl and runtime variant have different directions. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] installing Boost on HP-UX 10.20
[snip discussion about writing a first acc-tools.jam] > > lanczos:/home/tk/boost/libs/numeric/ublas> /home/tk/bjam -sTOOLS=acc > > ...patience... > > ...patience... > > ...patience... > > ...found 3664 targets... > > ...updating 72 targets... > > aCC-C++-action > > ../../../libs/numeric/ublas/test1/bin/test1/acc/debug/runtime- > > link-dynamic/test1.o > > Error 112: "test1/test1.cpp", line 9 # Include file > > not found. > > #include > > ^^ > > OK, I think you said you have aCC v. 1.21. On my server, 'aCC --version' > gives "HP ANSI C++ B3910B A.01.23", so it looks like my shop is at v. 1.23 > and my experiences should be close to your own. Either way, you may have a > couple problems to surmount when trying to compile clean room C++ source: Does anybody know if there's a difference with aCC on HPUX 11 (we're talking about version 10.20 here). Because when checking out the status pages for HPUX 11 they don't seem so bad. > > (1) Certain header files normally included with angle brackets have to be > included with ".h" on the back of the file name because HP decided to go > with backward compatibility over standard behavior. Files on my system that > I know have this problem are fstream.h, iostream.h and new.h. Your mileage > may vary according to compiler setup. Is there currently an option in boost to use the old include files, I did'nt see any. So would it be interesting to add the new headers that include the old headers in boost/compatibility ? > > (2) On my system, I am getting errors like this: > > Error 20: > "/home/jbh8632/projects/work/boost/boost_1_29_0/boost/detail/allocator.hpp" >, line 182 # ';' expected before '::'. >typedef std::size_tsize_type; > ^^ > The reason is that, on my system, the compiler is configured to use the > global anonymous namespace instead of std::. That may or may not affect > you. I have to deal with it for historical reasons peculiar to my local > installation that I will not describe here. But since there's no iostream but only iostream.h I suppose namespace std does'nt even exist ? (sorry can't check myself now since I only have a few days a week acces to an HPUX machine) > > Now, I am seeing another problem that seems to be related to the file > boost/config/compiler/hp_acc.hpp. I am getting an error from bjam while > using your acc jamfile that look like this: > > aCC-C++-action > libs/regex/build/bin/libboost_regex.a/acc/debug/runtime-link-dynamic/c_rege >x _traits.o > Error 119: > "/home/jbh8632/projects/work/boost/boost_1_29_0/boost/config/compiler/hp_ac >c .hpp", line 32 # #error "Compiler not supported or configured - > please reconfigure" > # error "Compiler not supported or configured - please reconfigure > > ... > > I looked at hp_acc.hpp and found a couple of lines that seem to conflict, > namely: > > #if (__HP_aCC <= 33100).. > > #if (__HP_aCC <= 33300) || !defined(BOOST_STRICT_CONFIG).. > > and > > #if __HP_aCC < 33000 > # error "Compiler not supported or configured - please reconfigure" > #endif.. > > I am getting the error from the last one. I wrote and compiled a small > program (attached below my sig) and it tells me that: > > __HP_aCC == 12300 > BOOST_STRICT_CONFIG not defined. > > Now, if my compiler version is < 3.30 (and it is), then I'll always get an > error from the last preprocessor test, even though the previous #if blocks > in hp_acc.hpp seem to conditionally accept compiler versions < 3.30. Note > that BOOST_STRICT_CONFIG may or may not be defined somewhere in the bjam > build process, so my little program is not the necessarily accurate there. Seems (from cvs log) that John Maddock, Jens and Aleksey have worked on hp_acc.hpp so I hope they can provide some insight here. As I said before I'm trying to help you (John Hagen) out but have little experience with aCC. > > Well, that is what I have for now. I will have to go through the library > and remove all the std:: namespace identifiers to get the Boost libs to > begin compiling on my system, but first I want to know if my hp_acc.hpp is > correct or not. It's from the 1.29 tarball off the Boost site. You definitly should avoid to do that ! (John, I would like to continue the discussion on the boost-ml since there are some people with experience with boost on HPUX that will be able to provide some more info, I'm not crosposting to jamboost since all jamboosters are also boosters) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: STL applied to disk
"Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > My best idea is the map, but I know that this is too slow. > > It makes my 40Mb test-case go from under a second to twelve seconds. > All CPU bound; not disk. That is bad. Agree. Commonly kind of hash table is used for this. Epecially it would be effective with keys of primitive types like int double char ... > > I have fuzzy ideas about sneaking a pointer into the sector buffer in place > of the object (till serialize), but the alignment and size problems here > worry me. Looks terrible :) > > Other things to consider with a cache of objects is that the wrapped > transaction will need to reserialize and destroy them all on commit, which > means that keeping the map in the database is not the right place; the > transaction has to find all of them. This is not problem at all. You don't need to destroy them untill commit is retaining. What you really need is to find objects belonging only to this transaction i.e. store write-locking transaction pointer/id inside persistent object. Each time object is modified it is added to its transaction context (commonly its transaction is defined by current transaction == transaction attached to current thread ). The other way can be single cache with locking information. In this case each cache entry contains information about read locks and single write lock. When you need to commit some trx than you just commit cache etries write locked by this transaction. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] Several Questions
Hi,
I'm starting to explore mpl a bit and I ran into a roadblock.
If I have a template that takes an argument that can be
a sequence (e.g. mpl::vector) or a regular old type, is
there any way, short of specialization, to determine whether
the parameter is a sequence? I'd like to avoid specializing
the template based on mpl guts that may change. Alternatively,
is there any way to manipulate the parameter to guarantee that
it is converted to a sequence (of one element) if it is not a
sequence?
Here's a second question. Suppose I have a "chain" of types
such that each type contains as a member the next type in the
chain. For example:
struct third;
struct second;
struct first;
struct first {
typedef second type;
};
struct second {
typedef third type;
};
struct third {
typedef boost::mpl::void_ type;
};
If I want to use this kind of intrusive sequence with mpl,
how would I go about defining begin<> and end<>? The headers
use something called begin_traits and end_traits but they
assume that the type passed is an mpl-style sequence that
has begin and end members defined.
I don't see how I can easily specialize begin<> and end<>
because I'd need a specialization for each of first, second
and third (in the real code there are many more of these).
I thought about designing some kind of wrapper that could
be used in specialization:
template
struct intrusive_list {
typedef Node::type type;
};
Then I could partially specialize begin<>/end<> on
intrusive_list. Is this a reasonable approach? Does mpl
provide some more convenient method to use these kinds of
sequences?
Here's one final puzzle: I have two type vectors that
I'd like to merge into one. The trick is that I want
to eliminate all duplicates. Since types cannot be
ordered (how does one define a less-than operation?)
it seems that type vectors cannot be easily sorted.
Thus to do a concat/copy while eliminating duplicates
would seem to be a very expensive task (search for
each candidate in the built-up list before adding it).
Any ideas here? I know I'm missing something important.
Great work by all on mpl -- I'm enjoying the exploration!
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re:Serlialization Library
From: [EMAIL PROTECTED] (Dave Harris)
>In-Reply-To: <[EMAIL PROTECTED]>
>On Sun, 17 Nov 2002 18:57:52 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> I did briefly consider this, but it seemed it wasn't worth it. My
> real main objection was that it broke the symetry of the load/save
> system. I have found this symmetry is very helpful to permit
> verification that serialization is correctly used. Also, my "thought
> experiments" along these lines considered fundamental types
> where copying was really an efficiency issue. Finally it
> became clear that I couldn't figure out a way to handle
> the versioning problem. So there you are
>OK... is the main problem access to the version number, or is there more
>to it?
Start with a simple case:
Suppose MyClass looks like
class MyClass
{
const int i;
int k;
version_type version(){
return 1;
}
static load(boost::basic_iarchive &ar, version_type i){
ar >> k;
}
MyClass(int _i) :
i(_i);
{
ar >> *this;
}
MyClass(boost::basic_iarchive &ar) :
i(?)
{
ar >> *this
}
};
How do we intialize the const member? That was the main reason for non default
constructor. But suppose that's not a problem? What about version 2
class MyClass
{
const int i;
int k;
const int j;// particular to version 2
int l; // particular to version 2
version_type version(){
return 2;
}
static load(boost::basic_iarchive &ar, version_type v){
ar >>k;
if(v > 1){
ar >> l;
}
}
MyClass(int _i, int _j) :
i(_i, _j)
{}
MyClass(boost::basic_iarchive &ar) :
i(?),
? if version? > 1 j(?)
{}
};
It wasn't obvious how to initialize constant members and base classes
where that initialization depends upon the version number.
It seems to me that access to the version number could be got with syntax
like:
>MyClass( boost::basic_iarchive &ar ) {
>boost::version_type version = ar.version( this );
>//
>}
>via an archive member template with a signature like:
>template
>version_type basic_iarchive::version( const T *p ) const;
>which seems to have enough information to look up typeid in the
>cobject_id_set.
given the above, I never even got to the point of considering how to get the
version number out of the stream at the right time. maybe it easy.
I never thought about it.
Robert Ramey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Object Factory
David Abrahams wrote: Now can we rename "factory" to "metaclass"? I just want to see smoke come out of peoples' ears! You know, this might be possible... If we can find a way to map members to function objects somewhat automatically, this might be realistic. After that, it's a simple sed script ;-) FactoryA b = FactoryA::create(); FactoryA c; A *a = b(10); // Returns new B(10) c = b; delete a; a = c(15); // Returns new B(10) I sure hope that's new B(15). Doh! Sorry about that one :) It definitely is B(15). I haven't submitted yet because it hasn't been updated to the new function class and the documentation isn't finished but since the topic came up, I thought I'd see what people thought. Here's the site: http://clam.rutgers.edu/~aliguori/factories/ Well, I'm excited. Great! I'll get working on updating it ASAP. If anyone has any ideas on how to make it even more generic, let me know (I'm very intrigued by the prospect of metaclasses in C++). Regards, Anthony Liguori ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Object Factory
Anthony Liguori <[EMAIL PROTECTED]> writes:
> One thing has always bothered me about Loki's class factories
> (namely, one paragraph in Modern C++ Design). The fact that virtual
> constructions aren't considered possible in C++. Specifically, in
> chapter 8.2 where Andrei gives an example of code that doesn't work
> in C++:
>
> // Warning-this is NOT C++
> // Assumes Class is a class that's also an object
>
> Class Read(const char *filename);
> Document *DocumentManager::OpenDocument(const char *filename)
> {
> Class theClass = Read(filename);
> Document *pDoc = new theClass;
> }
>
> So I wrote up a class that provided virtual constructor
> functionality. It actually allows for types to be treated as objects
> including storing types in any STL container. This allows for
> really advanced factory algorithms and all sorts of fun stuff.
Oh, neat!
> The basic usage is as follows:
>
> struct A
> {
> A(int a);
> };
>
> struct B : public A
> {
> B(int a);
> };
>
> typedef factory FactoryA;
Now can we rename "factory" to "metaclass"? I just want to see smoke
come out of peoples' ears!
> FactoryA b = FactoryA::create();
> FactoryA c;
>
> A *a = b(10); // Returns new B(10)
> c = b;
> delete a;
> a = c(15); // Returns new B(10)
I sure hope that's new B(15).
> The other interesting characteristic is that factories are
> compatiable with functions so bind functions can be used.
Of course!
> If a subclass has additional constructor parameters that had
> reasonable defaults, those parameters could be bind'ed which is
> something that no other factory implementation is capable of.
Very cool indeed!
> I haven't submitted yet because it hasn't been updated to the new
> function class and the documentation isn't finished but since the
> topic came up, I thought I'd see what people thought.
>
> Here's the site:
> http://clam.rutgers.edu/~aliguori/factories/
Well, I'm excited.
--
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: Object Factory
One thing has always bothered me about Loki's class factories (namely,
one paragraph in Modern C++ Design). The fact that virtual
constructions aren't considered possible in C++. Specifically, in
chapter 8.2 where Andrei gives an example of code that doesn't work in C++:
// Warning-this is NOT C++
// Assumes Class is a class that's also an object
Class Read(const char *filename);
Document *DocumentManager::OpenDocument(const char *filename)
{
Class theClass = Read(filename);
Document *pDoc = new theClass;
}
So I wrote up a class that provided virtual constructor functionality.
It actually allows for types to be treated as objects including storing
types in any STL container. This allows for really advanced factory
algorithms and all sorts of fun stuff. The basic usage is as follows:
struct A
{
A(int a);
};
struct B : public A
{
B(int a);
};
typedef factory FactoryA;
FactoryA b = FactoryA::create();
FactoryA c;
A *a = b(10); // Returns new B(10)
c = b;
delete a;
a = c(15); // Returns new B(10)
The other interesting characteristic is that factories are compatiable
with functions so bind functions can be used. If a subclass has
additional constructor parameters that had reasonable defaults, those
parameters could be bind'ed which is something that no other factory
implementation is capable of.
I haven't submitted yet because it hasn't been updated to the new
function class and the documentation isn't finished but since the topic
came up, I thought I'd see what people thought.
Here's the site:
http://clam.rutgers.edu/~aliguori/factories/
Regards,
Anthony Liguori
David B. Held wrote:
Christophe Meessen wrote:
[...]
Would there be any interrest in such thing for boost ? If there are
better solution I would be happy to know about it.
How does your library compare to Loki's class factories? Consult
Modern C++ Design for an explanation.
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] iterator_adaptors
Thomas Witt <[EMAIL PROTECTED]> writes: > My idea of the further schedule is > > - Check whether we all agree that this is the version to work from. I'm on board. > - Check in to sandbox > - See whether the interface can be made to work on a reasonable set > of compilers. The SC version was working on a _wide_ set of compilers. Fixing that once you check in your changes should be a priority. > - Documentation > - Port existing iterator_adaptors. Sounds good. -- 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] Boost License Issues
At 09:38 AM 11/19/2002, Andrew Koenig wrote: >Beman> Even something in the public domain should have a copyright, and a >Beman> license that says it is in the public domain. > >I think you should check this statement with a lawyer. I'd really like a knowledgeable intellectual property lawyer to review all Boost related license issues. But finding one willing to help has been a problem. Suggestions would be welcome. > Keith Gorlen, >the author of the NIH (National Institutes of Health) class library, >told me once that his work, being a ``US Government work'' is in the >public domain and *cannot* be copyrighted or licensed. That is, >*nothing* that anyone does with his work can legally prevent anyone >from copying it, so there is no meaningful way of licensing it. If I understand correctly, what was being requested was that it be possible to clearly associate each file with its legal status. So in the case you mention, I guess they would want to see a notice to the effect it was a "US Government work" and that it was in the public domain. We know some potential Boost users are delaying use of the libraries because of uncertainty about legal issues. We would like to address those issues, but really need help from a knowledgeable lawyer to do so. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Suggestion for iterator adaptors
Herve Bronnimann <[EMAIL PROTECTED]> writes: > On Tue, Nov 19, 2002 at 10:35:00AM -0500, David Abrahams wrote: >> > On Tuesday 19 November 2002 07:11, Herve Bronnimann wrote: >> >> Dave, Jeremy: one iterator adaptor I needed often (and once again today) >> >> is the projection on the first or second member of a pair. I could make >> >> it using projection_iterator<> and select1st, except that select1st is >> >> an std extension from SGI. I haven't found any other out-of-the-box way >> >> to do this, did I miss something? >> > >> > Not as far as I can see. >> >> Can't you just use make_projection_iterator with bind(&pair::first) ? > > Would work fine for boost::compressed_pair, but not for std::pair, > IIUC. In one, first is a member function, but in the other it's > just a public data member. bind supports data members. > Even assuming it works, would it inline the access to first > properly? No, it would "properly" store the data member pointer and indirect through 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
Re: [boost] Suggestion for iterator adaptors
On Tue, Nov 19, 2002 at 10:35:00AM -0500, David Abrahams wrote: > > On Tuesday 19 November 2002 07:11, Herve Bronnimann wrote: > >> Dave, Jeremy: one iterator adaptor I needed often (and once again today) > >> is the projection on the first or second member of a pair. I could make > >> it using projection_iterator<> and select1st, except that select1st is > >> an std extension from SGI. I haven't found any other out-of-the-box way > >> to do this, did I miss something? > > > > Not as far as I can see. > > Can't you just use make_projection_iterator with bind(&pair::first) ? Would work fine for boost::compressed_pair, but not for std::pair, IIUC. In one, first is a member function, but in the other it's just a public data member. Even assuming it works, would it inline the access to first properly? Just wondering. I like Thomas' suggestion about tuples. If it could be made to work for tuples AND std::pairs, it would get my vote. I'll think about it. Meanwhile, std::pair is pretty special among tuples due to its relation to std::map and other parts of the standard. But looking forward, tuples might become just as important... point taken. Thanks for the replies, -- Herve' ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Object Factory
Christophe Meessen wrote: [...] Would there be any interrest in such thing for boost ? If there are better solution I would be happy to know about it. How does your library compare to Loki's class factories? Consult Modern C++ Design for an explanation. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization to relational table
> Note! My knowledges about RTL are far from good. Just first glance. > I failed to compile rtl with my compiler. Will try once again. Which compiler are you using? So far we only support VC6 and g++. Arkadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization to relational table
Bohdan, If I understand correctly you have some way to split an object into fields. After you do it, what are your fields, strings? If so, this is good enough for putting an object in the grid, but we actually try to achieve different goals. We are implementing relational algebra -- joins, projections, etc. on relational tables that look like STL containers, and can have columns of arbitrary (built-in or user-defined) types. Templates allow us to achieve this in a typesafe manner. You are right, we can't dynamically define table schema, this is the price for type safety. Having said that, I am not sure that RTL is a suitable tool for XML serialization or any serialization at all (I maybe wrong, though). In fact RTL itself needs to collaborate with a serialization library. We think persistence and relational algebra are ortogonal things that are often put together because of RDBMS. Since RTL was mentioned in this context, I thought I needed to provide certain clarifications. Arkadiy "Bohdan" <[EMAIL PROTECTED]> wrote in message ardj19$l3r$[EMAIL PROTECTED]">news:ardj19$l3r$[EMAIL PROTECTED]... > > Sure it is, but I can't claim I understand what you mean in this particular > > case... > > > > Arkadiy > > Sorry, i was unclear. > I should look at RTL closer to find similarities and differences to my idea. > But first glance reveals difference between two: > > RTL : all classes are templates and one can adapt them to his needs. > library has a lot of compile time things. > > pros: > speed - a lot of compile time optimization. > cons: > size - each object has at least one table template instantination. > flexibility - one can not define table schema in runtime ( i'm not > sure ). > > > my : all classes are completely runtime. > table class is similar to std::ostream. > The only difference means that table contents > is structured. > it means that you can do following: > >class A; >in_memory_builder b; >table& t = b.create_table(); >A::define_table( t ); //user func >A x,y,z; >x.add_record( t ); //analogy to std::ostream is "t << x;" >y.add_record( t ); >z.add_record( t ); >gui_grid_control.show( t ); >to_xml( t, "out.xml" ); > >no templates! >pros: > fexibility - runtime table definition > size - fixed set of classes >cons: > speed - most probably a lot of virtual functions. > > > Note! My knowledges about RTL are far from good. Just first glance. > I failed to compile rtl with my compiler. Will try once again. > > regards, > bohdan > > > > > ___ > 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: STL applied to disk
"Wesley W. Terpstra" <[EMAIL PROTECTED]> writes: > On Tue, Nov 19, 2002 at 12:52:19PM -0500, David Abrahams wrote: >> "Wesley W. Terpstra" <[EMAIL PROTECTED]> writes: >> > On Tue, Nov 19, 2002 at 10:38:27AM -0500, David Abrahams wrote: >> >> I haven't been paying attention, but IIUC what you're proposing, these >> >> things are no longer conforming iterators. >> >> >> >> The way to make random access iterators over disk storage is to build >> >> an iterator which stores its value_type internally. You can even >> >> arrange for it to construct the value_type in its internal storage on >> >> demand, so that it doesn't store anything until it is dereferenced. >> > >> > I assume you mean they are not iterators because operator -> is >> > broken? >> >> And operator*. > >>From http://www.sgi.com/tech/stl/trivial.html: > > [1] The requirement for the return type of *x is specified as > "convertible to T", rather than simply T, because it sometimes > makes sense for an iterator to return some sort of proxy > object instead of the object that the iterator conceptually > points to. Proxy objects are implementation details rather > than part of an interface (one use of them, for example, is to > allow an iterator to behave differently depending on whether > its value is being read or written), so the value type of an > iterator that returns a proxy is still T. Yup. Proxies are allowed for input iterators, but not for forward, bidirectional, or random access iterators. > Similar things can be found for vect[offset]. Not unless you count vector (which nobody does). > I am printing > http://www.boost.org/libs/utility/iterator_adaptors.pdf to take home > with me this evening to see what is in there. > >> > What you are proposing however is flawed for several reasons. >> > >> > If I stored the value_type internally, this will break: >> > >> > map::iterator i = ...; >> > map::reference x = *i; >> > ++i; >> > x = ...; // what is x now pointing at? the wrong record. >> >> That code is already broken if it makes any assumptions about what >> x refers to after ++i. Sad but true. > > Really? Are you certain about this? It depends what type map is. If map is std::map, then the code isn't broken. However, if all you know is that map::iterator is an iterator, then yes, it's broken. > If you could give me a quote I would love to hear it. I know it is > not going to work for Input iterators, but what about a Forward > Iterator? No, input iterator is the one the proxy works for. The nearest quote is http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html/#299, which mentions the iterator with the internal cached value as a valid random-access iterator. > What about > map::pointer p = i->fn_returning_this(); > ++i; > > is p now invalid? If i is just some forward iterator, yes. > I know that in the STL containers it is generally still ok. (map, > set, list, etc) but that doesn't mean it is allowed. :-) You might want to check to see if there's any standard text which implies it's allowed for the standard containers. I think if it's not explicitly allowed, you should submit a DR. >> > Also, if you have two iterators pointing at the same thing, but keeping >> > distinct value_types internally, expressions like: >> >i->set_member_a(j->set_member_b(3) + 2); >> > will break -- only one of the changes will make it to disk. >> >> You can get around this by dynamically allocating the value_type and >> keeping a cache of active values in the container... if it's >> important. > > Errr... That is what I said after all in the part you just snipped. I realized that when I got there. > And, aren't you are the one who said "So what?" to partial conformance? Yes, but the problem you mention above is not a conformance problem. The issue lies in your definition of "pointing at the same thing". There's no guarantee that p == q implies &*p == &*q. > If the above expression fails to work, it is far worse than not providing > operator ->. The missing operator is detected at compile time; this could > take a long time to track down. It's only a bug user code relies on it. > Actually, even: > i->set_bar(2); > j->set_bar(4); > with i==j could write "2" to the disk with your internal value_type. > Clearly not what the user intended and very hard to detect reading it. QOI issue, I think. I'm not saying it's unimportant. It's just not a conformance issue. > Therefore, you MUST have a common allocated value_type, which means > you are going to need some way to find them. The information you > have at the time you want to find them is: > > the unique memory location of the serialized item > the unique sector+offset of the serialized item > the serialized item > a pointer to the session object, transaction, and database > > I seek an efficient way to do this. > So far, the sector+offset map is the best I can think of. OK. >> >
Re: [boost] 'function' idea
- Original Message - From: "Douglas Gregor" <[EMAIL PROTECTED]> > On Wednesday 13 November 2002 04:50 am, Aleksey Gurtovoy wrote: > > Paul Mensonides wrote: > > > This is unacceptable. What really needs to happen, is the > > > rules regarding declaration instantiation of template class > > > members need to be merged with type-deduction failure. I.e. > > > If the result is semantically invalid, the function is removed > > > from the overload set (excepting only a few things such as > > > applying 'const' to a type that is already 'const' and possibly > > > the reference to reference issue). Period. This is the only > > > safe way to go, and conveniently, would allow for all sorts of > > > traits tests that currently rely on compiler extensions. > > > > Agreed, that's basically what is wanted. The challenge is to execute > > something along the lines of the Doug's plan successfully ;). > > > > Aleksey > > Oops, I dropped the ball on this one. > > Last week I got the opportunity to ask Daveed Vandevoorde about this. > Specifically, I mentioned the gap in the type deduction failure rules > introduced by sizeof and asked if (a) the committee knew about this when they > drafted the clause and (b) what type of resolution we could expect if we > asked the committee to clarify this clause with respect to sizeof. Clever type traits are one thing, but they are a side-effect of the solution to a more general problem. Specifically, one template function declaration can permanently break an overload set--even if it is not selected. The solution to this is obvious, if type deduction yields nonsense, it should fail. It just so happens that we could exploit that solution in significant ways with traits and expression validity checking. > Daveed said that the intent of the clause is to ensure that the compiler is > never forced to create a type that is not well-formed. The the committee did > understand the problem sizeof caused when they drafted this clause, and that > they went through various forms of specification: listing all cases that > could succeed, creating a blanket statement that says that deduction fails if > there is any failure, or listing all cases that could fail. The impression I > got was that for any case that isn't well-formed and doesn't fall into one of > the categories for type-deduction failure, the program is ill-formed and the > compiler should emit a diagnostic. As it is now, yes. One single template function declaration can break an entire overload set permanently. As I said before, this is unacceptable. My primary interest here is to get rid of that hole in the system. My secondary interest is the amount of available traits-like constructs available would be greatly expanded. > (Aside: we should file a bug report with > EDG with Paul's example, because it falls into this case and should emit an > error instead of silently choosing the "wrong" one). We might still want to > submit a DR to get this clarified for sure. Before 4.3, sometimes Comeau did this right, sometimes wrong, and sometimes ice'd. It looks like they "fixed" this by just sealing off the whole area to prevent the ice. > What's this mean for us? Well, I think it kills the idea that a resolution to > a DR will give us the ability to check the compilability of any expression. What exactly are the reasons for specifying a list of possible failures? I can't imagine any reasoning that would validate such a list as the only way the type deduction can fail. Because of that list, what supposedly is a two-state type deduction with a pass-or-fail result, becomes a three-state type deduction with a pass-fail-or-error result--where a compiler has to go out of its way to catch the few errors in that list and "fail" type deduction instead of error. This just over-complicates the mechanism (and prevents us from exploiting it). > This brings me to a comment Daveed made during his talk (paraphrased): when > creating extensions for C++, don't forget what you actually want. We're > saying that we'd like to fix the type-deduction failure rules to act in a > certain way that makes our expression-checking hack work. We can't do this in > the old C++ (and no DR is going to change that), so we should step back and > ask "what exactly do we want to be able to do?" >From my perspective, this is a secondary concern. I consider this a major hole in the overloading/template mechanism. Expression checking is only an extremely nice side-effect of the *only* worthwhile solution to this problem. > I _think_ we want to be able to ask "what happens when we try to compile this > expression?". Then I think the result should be one of: > - ambiguous (the expression contains at least one ambiguity) > - access control violation (the expression will compile, but there is an > access violation that would cause a diagnostic) > - ill-formed (the expression is ill-formed, but not because of an ambiguity > or an access control violat
RE: [boost] Re:Serlialization Library
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 18:57:52 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> I did briefly consider this, but it seemed it wasn't worth it. My
> real main objection was that it broke the symetry of the load/save
> system. I have found this symmetry is very helpful to permit
> verification that serialization is correctly used. Also, my "thought
> experiments" along these lines considered fundamental types
> where copying was really an efficiency issue. Finally it
> became clear that I couldn't figure out a way to handle
> the versioning problem. So there you are
OK... is the main problem access to the version number, or is there more
to it?
It seems to me that access to the version number could be got with syntax
like:
MyClass( boost::basic_iarchive &ar ) {
boost::version_type version = ar.version( this );
//
}
via an archive member template with a signature like:
template
version_type basic_iarchive::version( const T *p ) const;
which seems to have enough information to look up typeid in the
cobject_id_set.
-- Dave Harris
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] (no subject)
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 19 Nov 2002 16:35:36 +0100 Wesley W. Terpstra
([EMAIL PROTECTED]) wrote:
> [On unnecessary copies]
> I think you may be interested to run this program:
It's a demonstration of the Return Value Optimisation, which I was already
aware of. The RVO is explicitly permitted, but not required, by the
standard. Some compilers don't provide it and it can't be relied upon.
> > void MyClass::load( basic_iarchive &ar ) {
> > MyClass( ar ).swap( *this );
> > }
>
> *This* might copy three times. (at least two)
> So, no better, and probably worse than above.
Not if swap() is written to avoid copying. If the members were vectors,
for example, this can be written to avoid copying the data in the vectors
at all. For example:
class MyClass {
vector member1;
vector member2;
public:
MyClass() {
}
MyClass( const MyClass &rhs ) :
member1( rhs.member1 ),
member2( rhs.member2 ) {
}
MyClass( basic_iarchive &ar ) {
ar >> member1 >> member2;
}
MyClass &operator=( MyClass &rhs ) {
MyClass( rhs ).swap( *this );
}
void MyClass::load( basic_iarchive &ar ) {
MyClass( ar ).swap( *this );
}
void swap( MyClass &rhs ) {
member1.swap( rhs.member1 );
member2.swap( rhs.member2 );
}
};
Now neither of:
MyClass example1( ar );
MyClass example2;
ar >> example2;
will copy the data in the vectors. To me this looks natural and elegant,
with the symmetry between the assignment operator and load function being
especially pleasing.
-- Dave Harris
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Named Template Parameters implementation
In-Reply-To: <[EMAIL PROTECTED]> On Mon, 18 Nov 2002 19:49:35 -0500 Beman Dawes ([EMAIL PROTECTED]) wrote: > The point I'm trying to make is that new designs shouldn't cripple > themselves trying to support old compilers. As far as I'm concerned, v6 is the current version of Microsoft's compiler. I know they've released v7, but it is too buggy to compile and link my code. I'd liked to be using it but I can't. Microsoft have acknowledged their bugs and say they will be fixed in v7.1, which I gather is due within about 5 months (1Q03). I hope to move on from v6 within a few months of that. I mention this just for information. -- Dave Harris ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Serialization Library Review
In-Reply-To: <[EMAIL PROTECTED]> On Sun, 17 Nov 2002 19:08:14 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote: > From: [EMAIL PROTECTED] (Dave Harris) > > [snip] > > ... but wouldn't produce very readable text files. > > readible text files are a minor convenience useful for debugging - > nothing more. OK. I think this area, of archives for human consumption, could be valuable. I have been wondering whether the newline() function should be made public for this reason. I have also been following the XML discussion with interest. Some mechanism for bracketing whole objects, and labelling fields, would also be useful for creating human-readable archives. And human-writable ones, for that matter. In a previous life (using Java) I have written unit tests that used XML strings to express "before" and "after" states. I found having such tools around to be very valuable. -- Dave Harris ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: STL applied to disk
On Tue, Nov 19, 2002 at 12:52:19PM -0500, David Abrahams wrote: > "Wesley W. Terpstra" <[EMAIL PROTECTED]> writes: > > On Tue, Nov 19, 2002 at 10:38:27AM -0500, David Abrahams wrote: > >> I haven't been paying attention, but IIUC what you're proposing, these > >> things are no longer conforming iterators. > >> > >> The way to make random access iterators over disk storage is to build > >> an iterator which stores its value_type internally. You can even > >> arrange for it to construct the value_type in its internal storage on > >> demand, so that it doesn't store anything until it is dereferenced. > > > > I assume you mean they are not iterators because operator -> is > > broken? > > And operator*. >From http://www.sgi.com/tech/stl/trivial.html: [1] The requirement for the return type of *x is specified as "convertible to T", rather than simply T, because it sometimes makes sense for an iterator to return some sort of proxy object instead of the object that the iterator conceptually points to. Proxy objects are implementation details rather than part of an interface (one use of them, for example, is to allow an iterator to behave differently depending on whether its value is being read or written), so the value type of an iterator that returns a proxy is still T. Similar things can be found for vect[offset]. I am printing http://www.boost.org/libs/utility/iterator_adaptors.pdf to take home with me this evening to see what is in there. > > What you are proposing however is flawed for several reasons. > > > > If I stored the value_type internally, this will break: > > > > map::iterator i = ...; > > map::reference x = *i; > > ++i; > > x = ...; // what is x now pointing at? the wrong record. > > That code is already broken if it makes any assumptions about what x > refers to after ++i. Sad but true. Really? Are you certain about this? If you could give me a quote I would love to hear it. I know it is not going to work for Input iterators, but what about a Forward Iterator? What about map::pointer p = i->fn_returning_this(); ++i; is p now invalid? I know that in the STL containers it is generally still ok. (map, set, list, etc) but that doesn't mean it is allowed. :-) > > Also, if you have two iterators pointing at the same thing, but keeping > > distinct value_types internally, expressions like: > > i->set_member_a(j->set_member_b(3) + 2); > > will break -- only one of the changes will make it to disk. > > You can get around this by dynamically allocating the value_type and > keeping a cache of active values in the container... if it's > important. Errr... That is what I said after all in the part you just snipped. And, aren't you are the one who said "So what?" to partial conformance? If the above expression fails to work, it is far worse than not providing operator ->. The missing operator is detected at compile time; this could take a long time to track down. Actually, even: i->set_bar(2); j->set_bar(4); with i==j could write "2" to the disk with your internal value_type. Clearly not what the user intended and very hard to detect reading it. Therefore, you MUST have a common allocated value_type, which means you are going to need some way to find them. The information you have at the time you want to find them is: the unique memory location of the serialized item the unique sector+offset of the serialized item the serialized item a pointer to the session object, transaction, and database I seek an efficient way to do this. So far, the sector+offset map is the best I can think of. > > The whole question revolves around: > > > > is the overhead of such a table justified by the benefit of > > allowing member methods to be called on objects within the > > container. > > It depends on whether you're advertising STL compatibility or not. If > not, do what ever you like and use a large, loud disclaimer when you > write "iterator" (in quotes) in your documentation. If so, you have to > bite the bullet and make the iterators conform. I really do want them to conform. Don't read otherwise into my writing. However, in the practical situation this comes from, speed and consistency of the data are probably more important than feature coverage. > > There are significant costs: > > the overhead of redundant cache > > (it is already cached at the sector level) > > the overhead of indexing the map > > (considerable if you are just deserializing an int) > > > > My current answer is "not justified". But, I am open to persuasion, > > especially in the form of an optimized solution. > > I think it's early to worry about optimization. Make it work first. An > implementation which lies about its "iterators" is broken. Man, that is a bit hard-line. If it fails to compile, that is far better than obscure crashes (or worse---data cor
[boost] Bracketing a stream (was: Serialization to relational table)
On Tue, Nov 19, 2002 at 06:07:23PM +0100, Wesley W. Terpstra wrote:
> The trick is to use the FUNCTION boundary of the serializor.
I have attached a working proto-type.
This is merely proof of concept; I am not sure whether one should bracket
fundamental types for instance.
The output is presently:
[ 1 [ 2 ] 3 4 [ 5 ] ]
but maybe should be:
[ [1] [ [2] ] [3] [4] [ [5] ] ]
What do people think?
I am certain someone smarter than I could make this even more clever.
---
Wes
// Example begins
// Compiles and works with g++-2.95.4
#include
using namespace std;
// Common Framework
class object_stream;
class streamer
{
protected:
object_stream* m_impl;
streamer(object_stream* stream) : m_impl(stream) { }
public:
template
object_stream& operator << (const T& x);
friend class object_stream;
};
class object_stream
{
protected:
streamer m_helper;
virtual void object_begin() = 0;
virtual void object_end () = 0;
public:
object_stream() : m_helper(this) { }
virtual ~object_stream() { }
operator streamer& ()
{ // Casted on return from method
object_end();
return m_helper;
}
// All fundamental types go here
virtual object_stream& operator << (int x) = 0;
// This catches all non-fundamental types and safely preserves
// our type information while calling
template
object_stream& operator << (const T& x)
{ // Don't use conversion routine to cast us (not end of object)
return *(m_helper << x).m_impl;
}
friend class streamer;
};
template
object_stream& streamer::operator << (const T& x)
{
m_impl->object_begin();
return *m_impl << x;
}
// Concrete streamer
class paran_object_stream : public object_stream
{
protected:
void object_begin() { cout << "[ "; }
void object_end () { cout << "] "; }
public:
paran_object_stream& operator << (int x)
{ cout << x << " "; return *this; }
};
class paran_streamer : public streamer
{
protected:
paran_object_stream m_obj;
public:
paran_streamer()
: streamer(&m_obj) // a bit bad since it is not init'd, but since
{ } // we won't do anything in the base-class, ok
};
// Generic user
struct Foo
{
int x;
};
streamer& operator << (streamer& o, const Foo& f)
{ return o << f.x; }
struct Bar
{
int a;
Foo b;
int c;
int d;
Foo e;
};
streamer& operator << (streamer& o, const Bar& b)
{ return o << b.a << b.b << b.c << b.d << b.e; }
// test
int main()
{
Bar b;
b.a = 1;
b.b.x = 2;
b.c = 3;
b.d = 4;
b.e.x = 5;
paran_streamer s;
s << b;
cout << endl;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 'function' idea
On Wednesday 13 November 2002 04:50 am, Aleksey Gurtovoy wrote: > Paul Mensonides wrote: > > This is unacceptable. What really needs to happen, is the > > rules regarding declaration instantiation of template class > > members need to be merged with type-deduction failure. I.e. > > If the result is semantically invalid, the function is removed > > from the overload set (excepting only a few things such as > > applying 'const' to a type that is already 'const' and possibly > > the reference to reference issue). Period. This is the only > > safe way to go, and conveniently, would allow for all sorts of > > traits tests that currently rely on compiler extensions. > > Agreed, that's basically what is wanted. The challenge is to execute > something along the lines of the Doug's plan successfully ;). > > Aleksey Oops, I dropped the ball on this one. Last week I got the opportunity to ask Daveed Vandevoorde about this. Specifically, I mentioned the gap in the type deduction failure rules introduced by sizeof and asked if (a) the committee knew about this when they drafted the clause and (b) what type of resolution we could expect if we asked the committee to clarify this clause with respect to sizeof. Daveed said that the intent of the clause is to ensure that the compiler is never forced to create a type that is not well-formed. The the committee did understand the problem sizeof caused when they drafted this clause, and that they went through various forms of specification: listing all cases that could succeed, creating a blanket statement that says that deduction fails if there is any failure, or listing all cases that could fail. The impression I got was that for any case that isn't well-formed and doesn't fall into one of the categories for type-deduction failure, the program is ill-formed and the compiler should emit a diagnostic. (Aside: we should file a bug report with EDG with Paul's example, because it falls into this case and should emit an error instead of silently choosing the "wrong" one). We might still want to submit a DR to get this clarified for sure. What's this mean for us? Well, I think it kills the idea that a resolution to a DR will give us the ability to check the compilability of any expression. This brings me to a comment Daveed made during his talk (paraphrased): when creating extensions for C++, don't forget what you actually want. We're saying that we'd like to fix the type-deduction failure rules to act in a certain way that makes our expression-checking hack work. We can't do this in the old C++ (and no DR is going to change that), so we should step back and ask "what exactly do we want to be able to do?" I _think_ we want to be able to ask "what happens when we try to compile this expression?". Then I think the result should be one of: - ambiguous (the expression contains at least one ambiguity) - access control violation (the expression will compile, but there is an access violation that would cause a diagnostic) - ill-formed (the expression is ill-formed, but not because of an ambiguity or an access control violation) - well-formed (the expression will compile. this does not guarantee that the definitions of functions called in the expression can be instantiated, but only guarantees that the declarations can be instantiated) Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: STL applied to disk
"Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Tue, Nov 19, 2002 at 10:38:27AM -0500, David Abrahams wrote:
> > "Wesley W. Terpstra" <[EMAIL PROTECTED]> writes:
> > > So... I am beginning to lean towards the "don't do that" approach where I
> > > simply don't allow the user to call member methods on items in the
> > > container. (And not let them take pointers) This allows at least the above
> > > optimization and a few others (like *i = *j; -- no deserialize&serialize)
> > > and probably more I don't forsee yet.
> >
> > I haven't been paying attention, but IIUC what you're proposing, these
> > things are no longer conforming iterators.
> >
> > The way to make random access iterators over disk storage is to build
> > an iterator which stores its value_type internally.
IMHO "stores pointer to value from cache internally" would be better.
>> You can even
> > arrange for it to construct the value_type in its internal storage on
> > demand, so that it doesn't store anything until it is dereferenced.
>
> I assume you mean they are not iterators because operator -> is broken?
> Yes I agree.
> Aside from that however, I believe they do conform to iterators.
>
> What you are proposing however is flawed for several reasons.
>
> If I stored the value_type internally, this will break:
>
> map::iterator i = ...;
> map::reference x = *i;
> ++i;
> x = ...; // what is x now pointing at? the wrong record.
With above just next record.
>
> Also, if you have two iterators pointing at the same thing, but keeping
> distinct value_types internally, expressions like:
> i->set_member_a(j->set_member_b(3) + 2);
> will break -- only one of the changes will make it to disk.
>
> ---
>
> I know that this could be solved with some sort of:
>
> struct Address
> {
> sectorptr_t sector;
> sectorlen_t record;
> };
>
> struct Object
> {
> Observable observable;
> T object;
> };
>
> std::map which I keep in for each database.
Isn't it cache ? Looks familiar :)
> Then, every time you want to dereference an iterator, you lookup the address
> in the table (deserializing if necessary), reference the observable and
> return the object.
>
> When the observable is not_observed, you remove the Object from the table
> and reserialize to disk.
>
> The whole question revolves around:
> is the overhead of such a table justified by the benefit of allowing
> member methods to be called on objects within the container.
No overhead. Rather you have overhead with constant deserializing.
Just make a list of all possible operations on object and you will
understand (i hope:) ) that cache class not only accelerates your
serialization/deserialization but also solves problem of
"pointer<->object on disk identity". Cache of pure data buffers
is much simpler but not need when you have object cache.
>
> There are significant costs:
> the overhead of redundant cache
> (it is already cached at the sector level)
> the overhead of indexing the map
> (considerable if you are just deserializing an int)
In my practice storing int is 1% vs complex object storing
is 99%. Constant serializing/deserializing is poor idea for
big object. But i see ... you are fighting for simplicity.
>
> My current answer is "not justified". But, I am open to persuasion,
> especially in the form of an optimized solution.
Ok lets order all problems:
Ex:
//legacy code {
class MyClass
{
string name;
};
void do_some_changes( MyClass & value )
{
value.name = "...";
...
}
//legacy code }
How are you going to : load object, do_some_changes on it and save ?
Most probably:
MyClass x = db[ 444 ] ;//copy #1
do_some_changes( x );
db[ 444 ] = x; //copy #2
Problem #1:
User may want just:
do_some_changes( db[444] ); //note! it can even compile on some comiplers.
Which is wrong untill you put serialization in destructor, but in this case you
have
frequent object serialization, which is slow and serialization/deserialization
can't
be synchronized:
construct instance1 -> deserialize1
change instance1.
construct instance2 -> deserialize2
change instance2.
destruct 2
destruct 1.
Changes from instance2 goes away.
Problem #2:
Why you think you can copy any object ?
Problem #3:
Even if you can. Why do you think that object copy is cheap ?
Problem #4:
User has some template algorithm which deals with generic stl container.
Algorithm expects object "pointer <-> disk buffer" identity when performing
const operations on your container which is norm for std::container.
I'm not sure if it is required by standart, but it seems logical to me.
---
MHO :
It would be better to implement buffer (POD?) disk container and object
disk container separately. I looks like they are pretty different things.
regards,
bohdan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/lis
Re: [boost] Borland C++ 5.5.1 problem with the new shared_ptr tests
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, November 19, 2002 3:04 PM
Subject: Re: [boost] Borland C++ 5.5.1 problem with the new shared_ptr tests
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > Borland C++ 5.5.1 fails the following test:
> > >
> > > struct X
> > > {
> > > X(): next() {}
> > > boost::shared_ptr next;
> > > };
> > >
> > > void test()
> > > {
> > > boost::shared_ptr p(new X);
> > > p->next = boost::shared_ptr(new X);
> > > BOOST_TEST(!p->next->next);
> > > p = p->next;
> > > BOOST_TEST(!p->next); // here
> > > }
> > >
> > The problem is here;
> >
> >p = p->next;
> >
> > This assignment is slicing. It is directly calling
> >
> > shared_count & operator= (shared_count const & r) // nothrow
> >
> > on the lvalue (p). The pointee (p.px) is destroyed during
> "pi_->release();"
> > but is not re-assigned.
> >
> > If the intention was that the assignment use:
> >
> > template
> > shared_ptr & operator=(shared_ptr const & r) // never throws
> >
> > then Borland doesn't use it.
>
> No. The intent is to use the automatically generated copy assignment
> operator. By default, it should do memberwise assignment, and the end
result
> should be exactly
>
> > shared_ptr & operator=(shared_ptr const & r) // never throws
> > {
> > px = r.px;
> > pn = r.pn; // shared_count::op= doesn't throw
> > return *this;
> > }
>
> that.
>
I see.
So bcc5.5.1 fails to generate (or use in this context?) the default
assignment op...
How do you plan to fix this...
defining it just for bcc,
or for all compilers? that is, can be any problem in defining operator=
always?
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Serialization & XML (was Serialization Library Review)
Dave, Yes, Python is certainly very powerful (expression-wise). I do not see a lot of "valid" (read "not using weird pointer arithemtic thingies") C++ value graphs that are not quite directly representable in Python. I actually believe that Python is more versatile than C++ in many aspects, as a theoretical guy enjoying first-class objects. See my previous mail for more information. Boost.Python should therefore be a mandatory tool for every serious developer ;-) David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Abrahams Sent: Tuesday, November 19, 2002 8:21 AM To: Boost mailing list Subject: Re: [boost] Serialization & XML (was Serialization Library Review) Matthias Troyer <[EMAIL PROTECTED]> writes: > On Tuesday, November 19, 2002, at 06:22 AM, David Bergman wrote: > >> Hi, >> >> This is a comment from the Java corner of the world: I have, as many >> other developers using Java, implemented serialization of objects onto >> XML. It is not that hard, although there might not exist (can anyone >> verify this?) a standardized (more or less...) "C++ Object XML Format". >> >> >> There are two alternatives: >> >> 1. Use an intelligible XML Application (yes, that is what the XML folks >> call the specific XML languages, such as XHTML...), giving not only >> platform independence (which I assume the serializer module already >> achieves...) but language independence, i.e., the object or value can be >> unmarshalled, or generated, by a Python program, much in the spirit of >> the good old XDR. > > As nice as the idea is, there are C++ types that cannot be > represented in Java. Just consider templates or multiple inheritance > (from two or more base classes where neither can be represented as a > Java interface) Multiple inheritance, including diamond-inheritance is easily represented in Python. -- 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: new initialization lib, any interest?
From: Thorsten Ottosen <[EMAIL PROTECTED]>
> From: "Yitzhak Sapir" <[EMAIL PROTECTED]>
> > On Wed, 9 Oct 2002, Thorsten Ottosen wrote:
> >
> > > The problem of missing a value in the assignment to
> > > the map is hypothetical. If I wan't to map int to int, I can make the
No, it isn't hypothetical. It is a reasonable situation to map
from one numeric type to another, and to use integers for the
initial values even when assigning to a floating point type.
> > > mapping just as clear by using newline or tabs:
> > >
> > > set_map( m ) += 1,22,33,45,6;
> > > set_map( m ) += 1,2
> > >2,3
> > > 3,4;
As you can see, tabs can be a problem. At least in mailing
lists! ;-)
> > Given that you yourself did not do well in giving an example of
> > separation with whitespace, I think this speaks strongly for a pair-wise
> > syntax.
I agree.
> maybe you didn't see my other reply? It was late :-) If I had tried to
> compile it I would have gotten one
> of your favorable compile-time errors. So to use your words, I don' t think
> it "speaks strongly" for anything.
> In fact, I would appreciate you'd not come up with false and irrelevant
> arguments.
They are neither false nor irrelevant arguments. He was,
however, exercising hyperbole. Your point, if I understand you
correctly, is that the compiler would have complained had you
been able to actually attempt to compile the above with a more
compliant compiler.
> > In any case, I'm against something like assign_map(m) += or
> > append_map(m) =. Does the first do a clear() before it assigns? Does the
> > second? The "set_map" or "append_map" or "assign_map" suggests one way,
> > the "+=" or "=" suggests another. This ambiguity does not occur with the
> > parenthesis form, as there is no way to specify "multiple" meanings. This
> > double meaning problem is also what led me to propose doing away with the
> > name altogether and having: m += 1,2, 2,3, 3,4, 5,6;
You make a great point.
> > The parenthesis form is not that hard. Add a space between the values and
> > the parenthesis, and the value isn't buried:
> >
> > init(m)( 1, 2 )( 2, 3 )( 3, 4 );
I don't put spaces within parenthetical expressions, so I'm
accustomed to code like this:
init(m)(1, 2)(2, 3)(3, 4);
I find that perfectly readable.
> > In this case white space does enhance readability, but the syntax
> > guarantees the user won't make a mistake.
I find the spaces distracting, but since they are not required,
but merely possible should your own sense of taste dictate them,
I have no problem either way.
> neither will he in the other case. ¨The concern is hypothetical and the
> interface for map and eg vector will be different which is much worse than
> having both operator= and operator+=.
The concern is not hypothetical. If you have a
std::map, you could easily initialize it with only
"pairs" of integers, and the compiler will be happy to convert
integers to doubles for you. How can you find an error if the
compiler doesn't flag it? How will you learn that you transposed
a 2 and a 3 in such a case? It depends upon how that
transposition affects the rest of your code. It may be invisible
in most circumstances.
> Spaces are always nice (I would always add spaces inside paranthesis as you
> did before), but the less parenthesis
> the better. The are still more desturbing than a comma. It might not be
> simple integers that are added:
>
> init( m)( "ssdsd", Class( 2, Cow( 3 ) ) )
>
> m += "dfedfe", Class( 2, Cow( 3 ) )
>
> the less parenthesis the better.
I find these readable:
init(m)("ssdsd", Class(2, Cow(3)));
m+= ("dfedfe", Class(2, Cow(3)));
Couldn't you use map-like notation:
init(m)["ssdsd"] = Class(2, Cow(3)), ["dfedfe"] = Class(2, Cow(3));
The idea is that init(m) would create an object that provides the
subscript operator which takes the map's key type as a parameter
and returns an object with an assignment operator which takes the
map's value type as a parameter. The assignment operator
would return the original "init" object. The "init" class
provides the comma operator to allow chaining as shown.
(Add whitespace to taste:
init(m)
["ssdsd"] = Class(2, Cow(3)),
["dfedfe"] = Class(2, Cow(3));
)
What could be more intuitive? (Efficiency may be another matter,
but it's intuitive, right?)
> >In your case, whitespace might
> > add something, but the user can still make a mistake. Even something
> > like:
> >
> > set_map(m) += 1,2, 2,3, 3,4, 5,6, 7,8, | 9,
> > 9,10, 11,12, 13,14, 15,16 17,18
> > 19,20;
> >
> > With the user screen margin occuring where the | passes is possible. In
> > this case, white space doesn't save him from this mistake. And it could
> > be hard to find.
>
> no. as I said earlier, a missing value will be caught at "bug-time" (~the
> first time the user runs the code).
You're assuming the code path containing t
Re: [boost] Borland C++ 5.5.1 problem with the new shared_ptr tests
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> A solution is to add a non-template assignment, at least only for
bcc5.5.1,
> as:
>
> shared_ptr & operator=(shared_ptr const & r) // never throws
> {
> px = r.px;
> pn = r.pn; // shared_count::op= doesn't throw
> return *this;
> }
>
> With this additional assignment, the test passes.
Applied, thanks. :-)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Serialization & XML (was Serialization Library Review)
Matthias, (in the following, "object" denotes any value, primitive or not...) It is obviously the case that there are object graphs in C++ that are not homologous to any object graph in languages such as Java or Python. Complexity is the price we C++ programmers pay for versatility and power... I would actually argue that Java and, to some extent, Python (although its dynamic character, with functions as even more first-class residents than the functors of C++) are isomorphically embedded in C++ in that sense, i.e., every object graph in those two languages are quite readily transformed to C++ graphs, with the corresponding semantics attached. But, one remark must be made: The "Web Service" kind of data, transferred via XML, most probably correspond to simple graphs in that they reside in the image of the embedding isomorphism mentioned above. I.e., in those situations where we have processing nodes in different language environments (or cross-language) situations, there might be a greatest common divisor. Even a divisor that small that good old VB will be a multiple ;-) Regarding your comment about a direct "ad-hoc" embedding of the marshalled binary data in a CDATA section, I totally agree, I just wanted to expose that simplistic alternative. The third alternative you mention, that of actually having a scheme provided by the user (read "programmer") is quite versatile (read "in the spirit of modern C++ development"). It might be quite a threshold though for most users. I strongly feel that either alternative 1 (a fixed XML Schema or DTD, considering or not considering poor non-C++ developers) or 2 (embedd the binary data in a CDATA section) must be present in conjunction with such a versatile approach, as a default setting. There are a lot of powerful user-provided schema alternatives for XML serailization in the soft world of Java, which I would be happy to communicate with whomever taking on the task of "the third alternative". A short note: I am a C++ developer, although I often wander in the shadow of garbace collections... Thanks for your comments, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthias Troyer Sent: Tuesday, November 19, 2002 2:09 AM To: Boost mailing list Subject: Re: [boost] Serialization & XML (was Serialization Library Review) On Tuesday, November 19, 2002, at 06:22 AM, David Bergman wrote: > Hi, > > This is a comment from the Java corner of the world: I have, as many > other developers using Java, implemented serialization of objects onto > XML. It is not that hard, although there might not exist (can anyone > verify this?) a standardized (more or less...) "C++ Object XML Format". > > > There are two alternatives: > > 1. Use an intelligible XML Application (yes, that is what the XML folks > call the specific XML languages, such as XHTML...), giving not only > platform independence (which I assume the serializer module already > achieves...) but language independence, i.e., the object or value can > be > unmarshalled, or generated, by a Python program, much in the spirit of > the good old XDR. As nice as the idea is, there are C++ types that cannot be represented in Java. Just consider templates or multiple inheritance (from two or more base classes where neither can be represented as a Java interface) > 2. Embed the binary output of the existing serializer in an XML > element. > This constrains the XML snippet to this particular serialization > algorithm, including, at least initially, to the C++ language. Sure, that is possible but probably not very suitable. I guess another alternative is 3. allow the support of a user-defined schema for his classes with as little constraints as possible. The questions now are: what are the present constraints? I do not know. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Object Factory
Hello
I recently met the need for an Object Factory. I according to some
configuration information I would instantiate different type of objects
derived from a same base class.
So I wrote a small and light STL class that would do just what I
wanted.It might be that such functionality could be usefull for other
people. I don't know if there is a standrad submission procedure or if
this is the way to suggest an idea or a draft implementation.
Here is the general usage principle.
In one .cxx file you instantiate the baseFactory singleton object. It is
accessed through static member variables so does not need to be declared
as extern.
// Declare the factory
Factory baseTypeFactory;
// Declare an instantiable class as global variable
Factory::Class derivedClass1(
"DerivedClassOne" );
// Declare another instantiable class as global variable
// In any .cxx file of the file one can declare a new dervied class
instantiable by the factory.
Factory::Class derivedClass1(
"DerivedClassTwo" );
int main()
{
...
// Building objects
MyBaseType * obj =
Factory::buildObject("DerivedClassTwo");
...
}
The default class key type is a string. But it may be changed into an
integer or anything else. The returned value is NULL if the key type
does not match any know class factory.
In the use case I had, the constructor needed an argument. So my version
adds an argument to the buildObject method that will be passed to the
constructor of the object called with new. To follow the STL standard
one should also be able to add a specific allocator type.
I am not a template expert. So the current implementation may not be the
one the might please everybody.
Would there be any interrest in such thing for boost ? If there are
better solution I would be happy to know about it.
--
cheers,
Ch. Meessen
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Borland C++ 5.5.1 problem with the new shared_ptr tests
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > Borland C++ 5.5.1 fails the following test:
> >
> > struct X
> > {
> > X(): next() {}
> > boost::shared_ptr next;
> > };
> >
> > void test()
> > {
> > boost::shared_ptr p(new X);
> > p->next = boost::shared_ptr(new X);
> > BOOST_TEST(!p->next->next);
> > p = p->next;
> > BOOST_TEST(!p->next); // here
> > }
> >
> The problem is here;
>
>p = p->next;
>
> This assignment is slicing. It is directly calling
>
> shared_count & operator= (shared_count const & r) // nothrow
>
> on the lvalue (p). The pointee (p.px) is destroyed during
"pi_->release();"
> but is not re-assigned.
>
> If the intention was that the assignment use:
>
> template
> shared_ptr & operator=(shared_ptr const & r) // never throws
>
> then Borland doesn't use it.
No. The intent is to use the automatically generated copy assignment
operator. By default, it should do memberwise assignment, and the end result
should be exactly
> shared_ptr & operator=(shared_ptr const & r) // never throws
> {
> px = r.px;
> pn = r.pn; // shared_count::op= doesn't throw
> return *this;
> }
that.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
Hi On Mon, Nov 18, 2002 at 07:20:58PM -0500, Beman Dawes wrote: > At 03:25 AM 11/18/2002, Pavol Droba wrote: > > >What I want to do in the future is to change default signature of trim to > > >something like you're proposing. There will be a variant with predicate > and > >a set of standard predicates. This way the locale stuff will be moved out > >to the predicate and will not confuse you any more, I hope :) > > Please post the signatures when you think they are stable. I think I > understand what you are planning, but it would be better to actually see > it. > There is new version of the lib in the sandbox. Now it contains predicate variants of all trim functions. I have also provided few default predicated to use. They are in string_funct.hpp header and can be accessed via following helper functions. if_isclassified( Type, Locale ) if_isspace( Locale ) if_isfrom( Seq ) all of them return instance to specific functor. isclassified was suggested by Genny Prota, isspace is just instantiation if isclassified with std::ctype_base::space as the type. isfrom functor lets you specify a range over set of elements you want to trim-out. I have used the same naming scheme as in standard, so all variants which accept predicate have _if suffix. A have left original variants ( those without suffix ) and they are mapping to isspace functor. Cheers, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: STL applied to disk
"Wesley W. Terpstra" <[EMAIL PROTECTED]> writes: > On Tue, Nov 19, 2002 at 10:38:27AM -0500, David Abrahams wrote: >> "Wesley W. Terpstra" <[EMAIL PROTECTED]> writes: >> > So... I am beginning to lean towards the "don't do that" approach where I >> > simply don't allow the user to call member methods on items in the >> > container. (And not let them take pointers) This allows at least the above >> > optimization and a few others (like *i = *j; -- no deserialize&serialize) >> > and probably more I don't forsee yet. >> >> I haven't been paying attention, but IIUC what you're proposing, these >> things are no longer conforming iterators. >> >> The way to make random access iterators over disk storage is to build >> an iterator which stores its value_type internally. You can even >> arrange for it to construct the value_type in its internal storage on >> demand, so that it doesn't store anything until it is dereferenced. > > I assume you mean they are not iterators because operator -> is > broken? And operator*. > Yes I agree. Aside from that however, I believe they do conform to > iterators. So what? > What you are proposing however is flawed for several reasons. > > If I stored the value_type internally, this will break: > > map::iterator i = ...; > map::reference x = *i; > ++i; > x = ...; // what is x now pointing at? the wrong record. That code is already broken if it makes any assumptions about what x refers to after ++i. Sad but true. > Also, if you have two iterators pointing at the same thing, but keeping > distinct value_types internally, expressions like: > i->set_member_a(j->set_member_b(3) + 2); > will break -- only one of the changes will make it to disk. You can get around this by dynamically allocating the value_type and keeping a cache of active values in the container... if it's important. > The whole question revolves around: > > is the overhead of such a table justified by the benefit of > allowing member methods to be called on objects within the > container. It depends on whether you're advertising STL compatibility or not. If not, do what ever you like and use a large, loud disclaimer when you write "iterator" (in quotes) in your documentation. If so, you have to bite the bullet and make the iterators conform. > There are significant costs: > the overhead of redundant cache > (it is already cached at the sector level) > the overhead of indexing the map > (considerable if you are just deserializing an int) > > My current answer is "not justified". But, I am open to persuasion, > especially in the form of an optimized solution. I think it's early to worry about optimization. Make it work first. An implementation which lies about its "iterators" is broken. -- 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] Borland C++ 5.5.1 problem with the new shared_ptr tests
> Borland C++ 5.5.1 fails the following test:
>
> struct X
> {
> X(): next() {}
> boost::shared_ptr next;
> };
>
> void test()
> {
> boost::shared_ptr p(new X);
> p->next = boost::shared_ptr(new X);
> BOOST_TEST(!p->next->next);
> p = p->next;
> BOOST_TEST(!p->next); // here
> }
>
The problem is here;
p = p->next;
This assignment is slicing. It is directly calling
shared_count & operator= (shared_count const & r) // nothrow
on the lvalue (p). The pointee (p.px) is destroyed during "pi_->release();"
but is not re-assigned.
If the intention was that the assignment use:
template
shared_ptr & operator=(shared_ptr const & r) // never throws
then Borland doesn't use it.
A solution is to add a non-template assignment, at least only for bcc5.5.1,
as:
shared_ptr & operator=(shared_ptr const & r) // never throws
{
px = r.px;
pn = r.pn; // shared_count::op= doesn't throw
return *this;
}
With this additional assignment, the test passes.
Can't check with other Borland compilers.
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: STL applied to disk
"Bohdan" <[EMAIL PROTECTED]> writes: > Do you mean that *i returns proxy (not object or reference) ? > Can you give some link where i can find rationale for this ? A rationale? No, "them's the rules". The reasons why don't matter much do they? > (except standart paper) I know there were talks about it in boost, > but i'm not sure i can easyly find this thread. You can read all about the subtleties of iterator requirements in the iterator adaptors paper: http://www.boost.org/libs/utility/iterator_adaptors.pdf >> The way to make random access iterators over disk storage is to build >> an iterator which stores its value_type internally. You can even >> arrange for it to construct the value_type in its internal storage on >> demand, so that it doesn't store anything until it is dereferenced. > > I was trying to convince Wesley to this approach but it is not easy > :) He claims that it is much easier to return proxy and serialize / > deserialize on assignment and cast, but I have feeling that it is > blind alley for stl on disk. You're right. It's not much good to provide sort-of-iterator things that break down when you try to use them in algorithms which are legitimately assuming real iterators. -- 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] Boost License Issues
Beman Dawes writes: > Even something in the public domain should have a copyright, and a > license that says it is in the public domain. Wrong. Something that is in the public domain is not copyrighted, and no license is needed to use it. If you intend for other people to use public-domain code you have written, then you should include an explicit statement that it is, in fact, in the public domain. But this is neither a copyright nor a license; it is, to the contrary, an assurance that you will not claim a copyright at some future date. > The lawyers that I have talked to view a file as poison if it isn't > covered by someone's explicit copyright and license. What about PCCTS? It has no copyright, and is widely used and included in Linux distributions. > In other words, a file silent about copyright and license is seen as a > time bomb What about a non-copyrighted work that clearly states that the work has been placed in the public domain? BTW, you failed to answer the original question: is there any reason why a license "must require that the license appear on all copies of the software source code"? Why do I, as an author, have to place any requirements at all on those who wish to use my code? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost License Issues
[2002-11-19] [EMAIL PROTECTED] wrote:
>> From: David Abrahams [mailto:[EMAIL PROTECTED]]
>> >
>> > I've checked the sources, and there are about 50 files lacking
>> > copyright statements. If there are no objections, I'll update them
>> > as appropriate (using the statements in other files of the library
>> > in question).
>>
>> Could you post a list of the files first?
>
>
>[Libraries]
>boost.compatibility
>boost.dynamic_bitset
>boost.format
>boost.graph
>boost.lambda
>Pending files
>boost.python
>boost.smart_ptr
{snip]
I think you did a limited search... only in the headers. There are many more
files without (C). For example most "Jamfile"s don't have one.
Could you post how you did the search... perhaps this is something for Beman
to add to the list of checks for releases.
-- grafik - Don't Assume Anything
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- 102708583@icq - Grafik666@AIM - [EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: STL applied to disk
On Tue, Nov 19, 2002 at 10:38:27AM -0500, David Abrahams wrote:
> "Wesley W. Terpstra" <[EMAIL PROTECTED]> writes:
> > So... I am beginning to lean towards the "don't do that" approach where I
> > simply don't allow the user to call member methods on items in the
> > container. (And not let them take pointers) This allows at least the above
> > optimization and a few others (like *i = *j; -- no deserialize&serialize)
> > and probably more I don't forsee yet.
>
> I haven't been paying attention, but IIUC what you're proposing, these
> things are no longer conforming iterators.
>
> The way to make random access iterators over disk storage is to build
> an iterator which stores its value_type internally. You can even
> arrange for it to construct the value_type in its internal storage on
> demand, so that it doesn't store anything until it is dereferenced.
I assume you mean they are not iterators because operator -> is broken?
Yes I agree.
Aside from that however, I believe they do conform to iterators.
What you are proposing however is flawed for several reasons.
If I stored the value_type internally, this will break:
map::iterator i = ...;
map::reference x = *i;
++i;
x = ...; // what is x now pointing at? the wrong record.
Also, if you have two iterators pointing at the same thing, but keeping
distinct value_types internally, expressions like:
i->set_member_a(j->set_member_b(3) + 2);
will break -- only one of the changes will make it to disk.
---
I know that this could be solved with some sort of:
struct Address
{
sectorptr_t sector;
sectorlen_t record;
};
struct Object
{
Observable observable;
T object;
};
std::map which I keep in for each database.
Then, every time you want to dereference an iterator, you lookup the address
in the table (deserializing if necessary), reference the observable and
return the object.
When the observable is not_observed, you remove the Object from the table
and reserialize to disk.
The whole question revolves around:
is the overhead of such a table justified by the benefit of allowing
member methods to be called on objects within the container.
There are significant costs:
the overhead of redundant cache
(it is already cached at the sector level)
the overhead of indexing the map
(considerable if you are just deserializing an int)
My current answer is "not justified". But, I am open to persuasion,
especially in the form of an optimized solution.
---
Wes
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: STL applied to disk
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Wesley W. Terpstra" <[EMAIL PROTECTED]> writes:
>
> > Sorry for the latency; was ill.
> >
> > A status update (since I was working without internet while sick).
> >
> > I have a working vector wrapper as a prototype. It supports every
> > operation and type specificied on the SGI site except i->foo(), and
> > vector::pointer is void*. The iterators are random access, if mutable
> > then *x = t; works and *x is convertable to T.
> >
> > One interesting detail was this code fragment:
> >
> > typedef JFA::VectorDB DB;
> > typedef DB::Session Session;
> >
> > JFA::Environment env = JFA::Guess("/tmp");
> > DB db(env, "test");
> >
> > JFA_BEGIN_TRANSACTION(t, env) // opens retry block
> > Session s = t(db);
> >
> > int k = 0;
> > Session::const_iterator i;
> > Session::iterator e = s.end(); // getting iterators is expensive
> > for (i = s.begin(); i != e; ++i) k += *i;
> >
> > JFA_END_TRANSACTION(t) // commits and closes block
> >
> > The interesting thing to note is that s.begin() and s.end() are MUTABLE
> > iterators. Accessing these requires write-locking the sector they are on.
> > Yes I could require ((const)s).begin(), but I think that this is bulky.
> >
> > However, I found that by returning a proxy object, I could delay the locking
> > till *i. This means that the above code does not write-lock at all.
> > (It also reads 40M in under half a second on my budget hardware :-)
> >
> > So... I am beginning to lean towards the "don't do that" approach where I
> > simply don't allow the user to call member methods on items in the
> > container. (And not let them take pointers) This allows at least the above
> > optimization and a few others (like *i = *j; -- no deserialize&serialize)
> > and probably more I don't forsee yet.
>
> I haven't been paying attention, but IIUC what you're proposing, these
> things are no longer conforming iterators.
Do you mean that *i returns proxy (not object or reference) ?
Can you give some link where i can find rationale for this ? (except standart
paper)
I know there were talks about it in boost, but i'm not sure i
can easyly find this thread.
> The way to make random access iterators over disk storage is to build
> an iterator which stores its value_type internally. You can even
> arrange for it to construct the value_type in its internal storage on
> demand, so that it doesn't store anything until it is dereferenced.
I was trying to convince Wesley to this approach but it is not easy :)
He claims that it is much easier to return proxy and serialize /
deserialize on assignment and cast, but I have feeling that it is
blind alley for stl on disk.
regards,
bohdan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost License Issues
Dave Steffen writes: > > Are companies worried that someone will pop up and claim > > enfringement of copyright and/or patent, > > and demand money (perhaps with menaces!)? > > Yep. [...] We can't use _any_ outside code unless the licencing term > _clearly_ allow us to do so without any IP entanglements. So what's wrong with simply stating, "This code placed in the public domain by its author, AUTHOR'S_NAME_HERE." Public domain means zero IP entanglements. As one example, the Purdue Compiler Construction Tool Set states, "PCCTS is in the public domain. An individual or company may do whatever they wish with source code distributed with PCCTS or the code generated by PCCTS, including the incorporation of PCCTS, or its output, into commercial software." ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost License Issues
> Is a reason that failing to claim copyright at least > may permit someone else to claim copyright > and then for them to restrict use of the software? No, if I put my own work into the public domain, another cannot then copyright it. They may, however, derive a new work from mine and copyright that derived work. However, that still leaves my work in the public domain. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization to relational table
On Tue, Nov 19, 2002 at 05:59:53PM +0300, Vladimir Prus wrote: > I'm not a database expert, so my knowledge may be just rusty. However, I > never heard about composite types in relational tables, and never seen > anything like that in MySQL. Looking at MySQL docs right now, I indeed see > no mention of composite types. Could you clarify, preferably with concrete > SQL syntax. SQL is not the only database. Other databases (mine for instance) do support composite types in keys and values. > How this mapping will be defined? Can you give some examples? Especially, > why this mapping can be defined in the same way as for serialization (given > additional "begin_composite/end_composite" hooks? See my mail of a few moments ago; I just solved this issue. > >>Of course, you might have Berkeley DB or something like that, which is > >>on disk map. But in this case, Robert's serialization > >>library would work just fine. And BTW, I'd like to have such thing. Well, then, stay tuned for libjfa. :-) = stl on disk. > >I don't know much about Berkley DB, but it looks like it is not relational > >db (record==serialized object ?). It is very limited comparing to fullblown > >relational database. Relational database like SQL are often implemented on top of things like berkley db. I believe MySQL does this for instance. --- Wes msg00737/pgp0.pgp Description: PGP signature
Re: [boost] Serialization to relational table
On Mon, Nov 18, 2002 at 07:21:32PM +0200, Bohdan wrote:
> I believe that XML can contain any data. But i suspect that
> XML garbaged with all serialization stuff will be
> 1. unreadeable
> 2. difficult to handle automatically (by other programs).
Yes. I completely concur.
> So i was thinking about simplifying Object <-> XML serialization.
> Recently there were talks about ditto & relational algebra libraries.
> Also there was message about stl container on disk.
> As i understand at least some of these libs require special kind
> of serialization: Object <-> Relational tuple (object-relational mapping).
> Having such mapping it would be easy to put Relational data to XML.
> And in this case XML will be very readable.
I agree... And your email has given me a brain-spasm.
I beleive one can do XML within the context of Robert's scheme properly if
he makes things a little more modular and uses a type-conversion trick I
just thought up.
Struct Bar
{
int x;
int y;
};
struct Foo
{
std::string name;
unsignedage;
Bar position;
std::string birthcity;
};
data_stream& operator << (data_stream& o, const Bar& b)
{ return o << "x" << b.x << "y" << b.y; }
data_stream& operator << (data_stream& o, const Foo& f)
{ return o << "name" << f.name << "age" << f.age
<< "position" << f.position << "birthcity" << f.birthcity; }
The goal is to be able to get this into, say:
joe
60
30
33
victoria
With the above information, you can serialize to a SOAP request, XML, a raw
stream (discard the names), a database, etc.
The question which was raised earlier regarding xml is, of course, how do
you infer the hierarchy from a stream of objects. I believe I can solve
this non-intrusively for streams without needing an "object_end" manipulator.
The trick is to use the FUNCTION boundary of the serializor.
class object_stream // has the actual stream operations (virtual like with
// Roberts serializor for overloading)
{
protected:
data_stream*helper;
public:
operator data_stream& ()
{ saw_object_end(); return *helper; }
};
class data_stream // never has descendants
{
protected:
object_stream* impl; // allow polymorphic stream targets
public:
template
object_stream& operator << (const T& x)
{ impl->saw_object_start(); return *impl << x; }
};
The plan is to use the type conversions implied by the stream declaration
function to get a fully paranthesized stream. This does away with the need
for those nasty hooks mentioned in an earlier email.
I bet that type trickery could further be used to coax the C++ compiler into
providing all the "name"s at once without recursing immediately. It would
certainly be sufficient to tell "name" appart from "value" since they
alternate.
If one could delay the recursion, then on input one could look at next named
field, compare to the fields we know we need to deserialize, and deserialize
out of order(!) to match the names (in the case of xml streamers). Or, in
the case of a straight serializor, deserialize in parameter order.
> I know this approach has some limitations and doesn't fit very well
> to serialization library design, but IMHO Object <-> relational tuple
> conversion would be very useful :
I disagree; I think I just bonded them. :-)
See below for the other half.
> 1. store/retrieve object to/from relational tables (in-memory & disk
> databases).
Completely agree
> 2. now collection of object can be represented in GUI. Ex: vector< MyObject
> >
>can be viewed and edited by user in some kind of grid.
Completely agree
> 3. putting/getting relational data to/from XML is much simpler than
>object <-> XML serialization.
Completely agree
> I think that this kind of serialization is completely different from
> serialization framework written by Robert and possibly it can solve
> XML serialization question.
>
> thoughts ?
I do not think it is different, merely more general.
Going along with the thoughts about how serialization is a name which
blankets many, many different needs, I think you could implement this as
an add-on the Robert's code by adding a derived serialization object that
expects additional name_stream serializors.
The best "serialization system" in the world I think would be to define
concrete categories of information about classes.
Maybe a serial_traits_uuid::uid
And a serial_traits_data::get&put // (default to >> and << )
Potentially more if there is a need.
Some helper objects which deal with seperable information, like:
the proposed re
[boost] Borland C++ 5.5.1 problem with the new shared_ptr tests
Borland C++ 5.5.1 fails the following test:
struct X
{
X(): next() {}
boost::shared_ptr next;
};
void test()
{
boost::shared_ptr p(new X);
p->next = boost::shared_ptr(new X);
BOOST_TEST(!p->next->next);
p = p->next;
BOOST_TEST(!p->next); // here
}
The other test cases (and there are lots!) pass, and the above passes with
my other compilers. Any insights are appreciated.
--
Peter Dimov
http://www.pdimov.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
On Tue, Nov 19, 2002 at 09:35:49AM -0500, Andrew Koenig wrote: > Joel> The author releases the software into the public domain. Ten > Joel> seconds later boost copyrights the software and releases it > Joel> under the Boost Public License... > > I believe that once something is in the public domain, it can no > longer be copyrighted. Is this statement true in all countries on the planet? -S ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
From: <[EMAIL PROTECTED]> > > From: David Abrahams [mailto:[EMAIL PROTECTED]] > > > > > > I've checked the sources, and there are about 50 files lacking > > > copyright statements. If there are no objections, I'll update them > > > as appropriate (using the statements in other files of the library > > > in question). > > > > Could you post a list of the files first? [...] > boost.smart_ptr > - > smart_ptr.hpp Fixed. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: STL applied to disk
"Wesley W. Terpstra" <[EMAIL PROTECTED]> writes:
> Sorry for the latency; was ill.
>
> A status update (since I was working without internet while sick).
>
> I have a working vector wrapper as a prototype. It supports every
> operation and type specificied on the SGI site except i->foo(), and
> vector::pointer is void*. The iterators are random access, if mutable
> then *x = t; works and *x is convertable to T.
>
> One interesting detail was this code fragment:
>
> typedef JFA::VectorDBDB;
> typedef DB::Session Session;
>
> JFA::Environment env = JFA::Guess("/tmp");
> DB db(env, "test");
>
> JFA_BEGIN_TRANSACTION(t, env) // opens retry block
> Session s = t(db);
>
> int k = 0;
> Session::const_iterator i;
> Session::iterator e = s.end(); // getting iterators is expensive
> for (i = s.begin(); i != e; ++i) k += *i;
>
> JFA_END_TRANSACTION(t) // commits and closes block
>
> The interesting thing to note is that s.begin() and s.end() are MUTABLE
> iterators. Accessing these requires write-locking the sector they are on.
> Yes I could require ((const)s).begin(), but I think that this is bulky.
>
> However, I found that by returning a proxy object, I could delay the locking
> till *i. This means that the above code does not write-lock at all.
> (It also reads 40M in under half a second on my budget hardware :-)
>
> So... I am beginning to lean towards the "don't do that" approach where I
> simply don't allow the user to call member methods on items in the
> container. (And not let them take pointers) This allows at least the above
> optimization and a few others (like *i = *j; -- no deserialize&serialize)
> and probably more I don't forsee yet.
I haven't been paying attention, but IIUC what you're proposing, these
things are no longer conforming iterators.
The way to make random access iterators over disk storage is to build
an iterator which stores its value_type internally. You can even
arrange for it to construct the value_type in its internal storage on
demand, so that it doesn't store anything until it is dereferenced.
--
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] Suggestion for iterator adaptors
Thomas Witt <[EMAIL PROTECTED]> writes: > Herve, > > On Tuesday 19 November 2002 07:11, Herve Bronnimann wrote: >> Dave, Jeremy: one iterator adaptor I needed often (and once again today) >> is the projection on the first or second member of a pair. I could make >> it using projection_iterator<> and select1st, except that select1st is >> an std extension from SGI. I haven't found any other out-of-the-box way >> to do this, did I miss something? > > Not as far as I can see. Can't you just use make_projection_iterator with bind(&pair::first) ? -- 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] Serialization Library Review
I have another minor comment: There are certain unclean code segements, like the following loading of a string: // note breaking a rule here - is could be a problem on some platform read_binary(const_cast(s.data()), size); I expect that these to will cleaned up before a final submission to boost Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] (no subject)
On Sun, Nov 17, 2002 at 07:09:00PM +, Dave Harris wrote:
> The benefit is encapsulated single-step construction without unnecessary
> copying. As far I can tell, you have in mind either:
>
> MyMember member1, member2;
> ar >> member1 >> member2;
> const MyClass mine( member1, member2 );
>
> or perhaps:
>
> MyMember load_myclass( basic_iarchive &ar ) {
> MyMember member1, member2;
> ar >> member1 >> member2;
> return MyClass( member1, member2 );
> }
>
> const MyClass mine( load_myclass( ar ) );
>
> Both of these involve extra copying. The first involves breaking
> encapsulation of MyClass, because the caller needs to know about all of
> MyClass's members. The second is more encapsulated (at the cost of yet
> more copying of the data) but still has load_myclass() doing the work that
> really belongs in the constructor.
I think you may be interested to run this program:
#include
using namespace std;
struct A {
const int y;
A() { cout << "Construct" << endl; }
A(const A& a) { cout << "Copy" << endl; }
~A() { cout << "Destroy" << endl; }
A(int x) : y(x) { cout << "Explicit construct" << endl; }
};
A foo() {
int somevar = 3;
return A(somevar);
}
int main() {
A boo = foo();
return 0;
}
Observe the *absence* of copies.
Therefore both examples you give above only need to copy the constructor
parameters, never the object. I am using g++ 2.95.4 and 3.2, however I think
this behaviour is also in VC++ and possibly specified in the standard.
> Constructors should construct. With the single-step approach, a load
> function (if desired) could look like:
>
> void MyClass::load( basic_iarchive &ar ) {
> MyClass( ar ).swap( *this );
> }
*This* might copy three times. (at least two)
So, no better, and probably worse than above.
> > Your method would require that every class that uses serialization
> > and but no default constructor have code in it that knows about
> > archives. Non intrusive serialization could be be implemented in
> > this case.
That is not the case; his solution allows making the serialization method as
a template specialization. It could construct the object however necessary.
> Incidently, for some classes the MyClass( MyMember, MyMember ) constructor
> would have to be added specifically for serialisation anyway. We are
> serialising the /internals/ of the class. Those internals won't
> necessarily form part of the public interface.
I think you have a really good point here. :-)
OTOH, there is nothing he can do about this case.
This is the price of data hiding.
---
Wes
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
>> That fact does not gainsay what I said earlier: It is not >> possible to license public-domain material. Joel> I think we are in agreement...it is meaningless or impossible to license Joel> public-domain material...however, just the act of putting a license Joel> notice in the public-material is enough to make it a derivative work Joel> which you can copyright and then license... I think not. I'm pretty sure that the addition has to be intellectually significant, and if the license agreement is all that's added, there's nothing to stop someone from simply taking it out. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
> That fact does not gainsay what I said earlier: It is not > possible to license public-domain material. I think we are in agreement...it is meaningless or impossible to license public-domain material...however, just the act of putting a license notice in the public-material is enough to make it a derivative work which you can copyright and then license... ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
Joel> Once something has been released into the public domain, then it Joel> is free. I can use it to create a derivative work under my own Joel> copyright. The derivative work can have very minimal changes Joel> such as simple formatting. For examples look at any of the Joel> republished classic texts. Note the copyrights on them. Also Joel> look at the GRASS project Yes, you can add your own content and copyright that content. That fact does not gainsay what I said earlier: It is not possible to license public-domain material. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
IANAL... Once something has been released into the public domain, then it is free. I can use it to create a derivative work under my own copyright. The derivative work can have very minimal changes such as simple formatting. For examples look at any of the republished classic texts. Note the copyrights on them. Also look at the GRASS project Which was originally public domain from the Army and now exists in a GPL version and in one or two commercial products. http://grass.ibiblio.org/index2.html Joel From: Andrew Koenig <[EMAIL PROTECTED]> Date: 19 Nov 2002 09:35:49 -0500 To: Boost mailing list <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subj: Re: [boost] Boost License Issues Joel> The author releases the software into the public domain. Ten Joel> seconds later boost copyrights the software and releases it Joel> under the Boost Public License... I believe that once something is in the public domain, it can no longer be copyrighted. Anyone who likes can attach any kind of notice to it, but those notices have no effect because the original item is in the public domain. My understanding is that this state of affairs is one reason why the Free Software Foundation refuses to distribute the source code for the implementation of the Icon programming language: The authors (University of Arizona) have placed the implementation in the public domain, but the FSF distributes only material that is covered by the GPL. -- Andrew Koenig, [EMAIL PROTECTED], http://www.research.att.com/info/ark ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization to relational table
Bohdan wrote:
"Vladimir Prus" <[EMAIL PROTECTED]> wrote in message
arb8od$c87$[EMAIL PROTECTED]">news:arb8od$c87$[EMAIL PROTECTED]...
Bohdan wrote:
I believe that XML can contain any data. But i suspect that
XML garbaged with all serialization stuff will be
1. unreadeable
2. difficult to handle automatically (by other programs).
So i was thinking about simplifying Object <-> XML serialization.
Recently there were talks about ditto & relational algebra libraries.
Also there was message about stl container on disk.
As i understand at least some of these libs require special kind
of serialization: Object <-> Relational tuple (object-relational mapping).
Having such mapping it would be easy to put Relational data to XML.
And in this case XML will be very readable.
Wouldn't there be a problem with converting object with variable size?
How can you store vector in a relational database? I don't see an easy
way.
Relational record field can be of simple type (int, char[n], double) or
it can be other nested table. In your exapmle:
vector< int >->
record
{
nested_table_field
{
record
{
field
}
}
}
I'm not a database expert, so my knowledge may be just rusty. However, I never
heard about composite types in relational tables, and never seen anything like
that in MySQL. Looking at MySQL docs right now, I indeed see no mention of
composite types. Could you clarify, preferably with concrete SQL syntax.
I know this approach has some limitations and doesn't fit very well
to serialization library design, but IMHO Object <-> relational tuple
conversion would be very useful :
1. store/retrieve object to/from relational tables (in-memory & disk
databases).
Do you think that automatic mapping is possible in case of relational
database?
No. Serialization lib also is not automatic. I think user should define mapping
information manually. But if you have only one side object definition (header
file)
or relational dabase schema (DDL) and you want to build other side automatically
than it is possible to create some tool that does it automatically.
How this mapping will be defined? Can you give some examples? Especially,
why this mapping can be defined in the same way as for serialization (given
additional "begin_composite/end_composite" hooks?
Of course, you might have Berkeley DB or something like that, which is
on disk map. But in this case, Robert's serialization
library would work just fine. And BTW, I'd like to have such thing.
I don't know much about Berkley DB, but it looks like it is not relational
db (record==serialized object ?). It is very limited comparing to fullblown
relational database.
It's just a different beast.
But i agree it would be very useful to have something
like that.
OK.
I can see it as some kind of "builder" interface:
- create table
- add field of
- add nested-table field
simple example:
class A
{
public:
int x;
char y[100];
static void define_table( builder & b, table& t )
{
b.define_field( t, "X", int_field );
b.define_field( t, "Y", char_field, 100 );
}
void add_record( table& t )
{
record& r = t.new_record();
r[ "X" ] = x;
r[ "Y" ] = y;
r.save();
}
};
Ah.. so here's example. The only problem with implementing this
in the same way as for serialization, is that you'd need to
define database structure before serializing. It's quite possible,
if the 'reflection' layer is designed to support this use case.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization to relational table
> Sure it is, but I can't claim I understand what you mean in this particular > case... > > Arkadiy Sorry, i was unclear. I should look at RTL closer to find similarities and differences to my idea. But first glance reveals difference between two: RTL : all classes are templates and one can adapt them to his needs. library has a lot of compile time things. pros: speed - a lot of compile time optimization. cons: size - each object has at least one table template instantination. flexibility - one can not define table schema in runtime ( i'm not sure ). my : all classes are completely runtime. table class is similar to std::ostream. The only difference means that table contents is structured. it means that you can do following: class A; in_memory_builder b; table& t = b.create_table(); A::define_table( t ); //user func A x,y,z; x.add_record( t ); //analogy to std::ostream is "t << x;" y.add_record( t ); z.add_record( t ); gui_grid_control.show( t ); to_xml( t, "out.xml" ); no templates! pros: fexibility - runtime table definition size - fixed set of classes cons: speed - most probably a lot of virtual functions. Note! My knowledges about RTL are far from good. Just first glance. I failed to compile rtl with my compiler. Will try once again. regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: STL applied to disk
Sorry for the latency; was ill.
A status update (since I was working without internet while sick).
I have a working vector wrapper as a prototype. It supports every
operation and type specificied on the SGI site except i->foo(), and
vector::pointer is void*. The iterators are random access, if mutable
then *x = t; works and *x is convertable to T.
One interesting detail was this code fragment:
typedef JFA::VectorDBDB;
typedef DB::Session Session;
JFA::Environment env = JFA::Guess("/tmp");
DB db(env, "test");
JFA_BEGIN_TRANSACTION(t, env) // opens retry block
Session s = t(db);
int k = 0;
Session::const_iterator i;
Session::iterator e = s.end(); // getting iterators is expensive
for (i = s.begin(); i != e; ++i) k += *i;
JFA_END_TRANSACTION(t) // commits and closes block
The interesting thing to note is that s.begin() and s.end() are MUTABLE
iterators. Accessing these requires write-locking the sector they are on.
Yes I could require ((const)s).begin(), but I think that this is bulky.
However, I found that by returning a proxy object, I could delay the locking
till *i. This means that the above code does not write-lock at all.
(It also reads 40M in under half a second on my budget hardware :-)
So... I am beginning to lean towards the "don't do that" approach where I
simply don't allow the user to call member methods on items in the
container. (And not let them take pointers) This allows at least the above
optimization and a few others (like *i = *j; -- no deserialize&serialize)
and probably more I don't forsee yet.
On Wed, Nov 13, 2002 at 06:06:42PM +0200, Bohdan wrote:
> "Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > You get a transaction object from the environment.
> > You get a database object from the environment.
> > You combine the two to get a session object.
> > The session looks like an stl map (it issues iterators).
> > When you commit the transaction all the sessions using that transaction are
> > invalidated as are all the iterators that they issued.
>
> Not necessary. Generally transaction class has two methods
> for commiting: commit and commit retaining (or checkpoint).
> Later retains transaction contex.
Good point. Presently my transaction manager does not support checkpoint (I
keep all the dirty write buffers in RAM [I know... just no time to make it
better yet]).
I think a checkpoint operation could simply write and release all the
unreferenced dirty buffers to disk without invalidating the sessions,
iterators, and references. So, this does not collide with my current design.
> Hand-written serialization is very error-prone thing. IMHO it would be good
> to supply some default serialization capability for user.
I do agree; but I want to reduce coupling.
I have not seen a serialization library compelling enough to bind to it.
> As i understand you are going to mange binary data blocks and sort them
> using part of this block.
Yes, that is exactly what I am doing.
> IMO this is too limited appoach. Actually, "key part" of your MapDatabase
> sould be relational table. I mean that user will be limited to some set of
> key types (int, char, varchar,datetime). Some complicated key types will
> be not possible in this case.
Yes, I lost a lot of sleep over this.
However, I eventually concluded that ANY tuple of ANY fundamental types can
be serialized into a string with an approriate lexical sort order.
(I actually have a formal constructive proof of this)
[ It is possible to deal with variable data by escaping nulls and appending
a null on the end, it is sufficient just dump floats and ints in network
byte-order, etc. ]
Since my primary goal is speed (I even expose the underlying sector buffers
to the stl-like wrappers so they can avoid virtual method calls for within
sector op.s), a user callback comparison function would be quite costly.
> But! I did not say this is poor way. I'm just not sure.
I am not sure either, but I do know that it is a greatly simplifying
assumption. I also know that a sufficiently power-serialization library
could make the tuple case work.
Finally, one of my on-disk structures is using front-coding.
So I really do need lexical sort order for this case.
> > >1. You need disk to reduce memory usage.
> > >2. You need disk to persist objects.
> >
> > I desire both of the two properties, you want me to choose? :-)
>
> Definitely! i don't think you can mix this two approaches.
> Personally i prefer 2. You can use it for 1, but not vice versa.
> In 1 you put (automatically) on disk only something you don't need.
> In 2 you put in memory only something you need.
I see. Since I am transactional and use a reference count to hold pages in
memory I think I am #2. However, as I stated, I desire both. :-)
But if you mean "Am I a glorified VM swapper
Re: [boost] Serialization & XML (was Serialization Library Review)
Beman Dawes wrote: At 09:21 AM 11/18/2002, Vladimir Prus wrote: >I believe that the biggest problem is that the current library does >not have any "begin class serialization"/"end class serialization" hooks, >which archive classes can interpret. IOW, you want to surround a >serializated >class with and , but the library passes only a >stream >of ints to you arhive class. > >Some other library (which name I can't remember now, sorry), used something >like 'describe', and there were explicit 'beginComposite' function. That was Jens' library. Uhmm... no. I was talking about yet another library (still can't remember the name). But the fact that it used begin/end functions tells something that it's really needed. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] stale anoncvs_boost lock in boost/
"Peter Dimov" <[EMAIL PROTECTED]> writes: > cvs server: [06:23:47] waiting for anoncvs_boost's lock in > /cvsroot/boost/boost/ > boost > cvs server: [06:24:17] waiting for anoncvs_boost's lock in > /cvsroot/boost/boost/ > boost > cvs server: [06:24:47] waiting for anoncvs_boost's lock in > /cvsroot/boost/boost/ > boost Hi Peter, Can you submit a SourceForge support request for this? Thanks, 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] Boost License Issues
Beman> Even something in the public domain should have a copyright, and a Beman> license that says it is in the public domain. I think you should check this statement with a lawyer. Keith Gorlen, the author of the NIH (National Institutes of Health) class library, told me once that his work, being a ``US Government work'' is in the public domain and *cannot* be copyrighted or licensed. That is, *nothing* that anyone does with his work can legally prevent anyone from copying it, so there is no meaningful way of licensing it. -- Andrew Koenig, [EMAIL PROTECTED], http://www.research.att.com/info/ark ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
Joel> The author releases the software into the public domain. Ten Joel> seconds later boost copyrights the software and releases it Joel> under the Boost Public License... I believe that once something is in the public domain, it can no longer be copyrighted. Anyone who likes can attach any kind of notice to it, but those notices have no effect because the original item is in the public domain. My understanding is that this state of affairs is one reason why the Free Software Foundation refuses to distribute the source code for the implementation of the Icon programming language: The authors (University of Arizona) have placed the implementation in the public domain, but the FSF distributes only material that is covered by the GPL. -- Andrew Koenig, [EMAIL PROTECTED], http://www.research.att.com/info/ark ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Suggestion for iterator adaptors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Herve, On Tuesday 19 November 2002 07:11, Herve Bronnimann wrote: > Dave, Jeremy: one iterator adaptor I needed often (and once again today) > is the projection on the first or second member of a pair. I could make > it using projection_iterator<> and select1st, except that select1st is > an std extension from SGI. I haven't found any other out-of-the-box way > to do this, did I miss something? Not as far as I can see. As a sidenote. From my experience you will run into the projection/transform problem quite frequently. IIRC projection iterators cannot be used on base iterators that don't have real reference types. > > I find them especially useful in connection with map::iterator, since > std::map does not have a value_iterator. I guess that alone provides the > rationale for including such an iterator adaptor, not to mention better > support of std::pair. Actually, I'd like to see a more general solution for all kind of tuple like types. Smth like typedef select_iterator<0, std::map::iterator > key_iterator_t; Btw, templated typedefs anybody ? > > It's simple enough to make two adaptors, so if you don't see anything > wrong with it, I'm proposing the patch for you. I'll even write the > corresponding portion of the documentation if you go ahead with it. > Hope you like it, I like the idea, and yes I do believe there is a real need. There are just some issues to be sorted out. I'd like to postpone this until the new iterator_adaptor version is finished. Thanks Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE92kr/0ds/gS3XsBoRAquxAJ4yr6ZLp/LRhxjYDyW6bZHrqrpYBgCeO7E+ b7Ebbr85gMKFXrqBFqFMr/E= =u8Oq -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] stale anoncvs_boost lock in boost/
cvs server: [06:23:47] waiting for anoncvs_boost's lock in /cvsroot/boost/boost/ boost cvs server: [06:24:17] waiting for anoncvs_boost's lock in /cvsroot/boost/boost/ boost cvs server: [06:24:47] waiting for anoncvs_boost's lock in /cvsroot/boost/boost/ boost -- Peter Dimov http://www.pdimov.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator_adaptors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Tuesday 19 November 2002 14:47, Jeremy Siek wrote: > Thomas, have you checked your new version in yet? I am waiting for Dave's comments. Beside from that I need sandbox access. Can you arrange this? My uid is witt. My idea of the further schedule is - - Check whether we all agree that this is the version to work from. - - Check in to sandbox - - See whether the interface can be made to work on a reasonable set of compilers. - - Documentation - - Port existing iterator_adaptors. TIA Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE92kdh0ds/gS3XsBoRAs/jAJ4jRWjQnJsphNBPiEXIdwnJ/PKTrQCeNfIN Rv2ULe3NwvLbLz3KZxF1cMw= =tPdC -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost License Issues
> From: David Abrahams [mailto:[EMAIL PROTECTED]] > > > > I've checked the sources, and there are about 50 files lacking > > copyright statements. If there are no objections, I'll update them > > as appropriate (using the statements in other files of the library > > in question). > > Could you post a list of the files first? [Libraries] boost.compatibility boost.dynamic_bitset boost.format boost.graph boost.lambda Pending files boost.python boost.smart_ptr boost.compatibility - compatibility/cpp_c_headers/cassert compatibility/cpp_c_headers/cctype compatibility/cpp_c_headers/cerrno compatibility/cpp_c_headers/cfloat compatibility/cpp_c_headers/climits compatibility/cpp_c_headers/clocale compatibility/cpp_c_headers/cmath compatibility/cpp_c_headers/csetjmp compatibility/cpp_c_headers/csignal compatibility/cpp_c_headers/cstdarg compatibility/cpp_c_headers/cstddef compatibility/cpp_c_headers/cstdio compatibility/cpp_c_headers/cstdlib compatibility/cpp_c_headers/cstring compatibility/cpp_c_headers/ctime compatibility/cpp_c_headers/cwchar compatibility/cpp_c_headers/cwctype boost.dynamic_bitset - dynamic_bitset_fwd.hpp boost.format - format/format_config.hpp boost.graph - graph/adjacency_iterator.hpp graph/adjacency_list_io.hpp graph/bandwidth.hpp graph/create_condensation_graph.hpp graph/dag_shortest_paths.hpp graph/detail/bitset_adaptor.hpp graph/detail/incremental_components.hpp graph/detail/list_base.hpp graph/graph_archetypes.hpp graph/graph_selectors.hpp graph/graph_test.hpp graph/iteration_macros_undef.hpp boost.lambda - lambda/core.hpp Pending files - pending/container_traits.hpp pending/cstddef.hpp pending/detail/disjoint_sets.hpp pending/detail/property.hpp pending/fenced_priority_queue.hpp pending/fibonacci_heap.hpp pending/iterator_adaptors.hpp pending/iterator_tests.hpp pending/property.hpp pending/queue.hpp pending/stringtok.hpp boost.python - python/detail/api_placeholder.hpp python/detail/python22_fixed.h python/dict.hpp python/str.hpp python/tuple.hpp boost.smart_ptr - smart_ptr.hpp ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization to relational table
"Bohdan" <[EMAIL PROTECTED]> wrote in message ardf7q$4h3$[EMAIL PROTECTED]">news:ardf7q$4h3$[EMAIL PROTECTED]... > > "Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message > arc2ra$nhv$[EMAIL PROTECTED]">news:arc2ra$nhv$[EMAIL PROTECTED]... > > "Bohdan" <[EMAIL PROTECTED]> wrote in message > > arb73a$2gm$[EMAIL PROTECTED]">news:arb73a$2gm$[EMAIL PROTECTED]... > > > > > Recently there were talks about ditto & relational algebra libraries. > > > Also there was message about stl container on disk. > > > As i understand at least some of these libs require special kind > > > of serialization: Object <-> Relational tuple (object-relational mapping). > > > > Relational algebra library (RTL) doesn't REQUIRE object-relational > > mapping -- it ALLOWS it. The object can be mapped either to a field or to a > > tuple -- this is up to the library user. > > World is so small :) Sure it is, but I can't claim I understand what you mean in this particular case... Arkadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::graph - incorrect answers withdikjstra_shorts_paths
Jeremy: Did you have any time to look into this? Marc "Jeremy Siek" <[EMAIL PROTECTED]> wrote in message news:<2147483647.1037316564@[192.168.1.102]>... > 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 > === Email transmissions can not be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. In addition, the information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution,or copying of this communication, disclosure of the parties to it, or any action taken or omitted to be taken in reliance on it, is strictly prohibited, and may be unlawful. If you are not the intended recipient please delete this email message. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Serialization to relational table
"Joachim Achtzehnter" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Today, in a message to boost, Vladimir Prus wrote:
> >
> > Bohdan wrote:
> > >
> > > serialization: Object <-> Relational tuple (object-relational mapping).
> >
> > Wouldn't there be a problem with converting object with variable size?
> > How can you store vector in a relational database? I don't see an
> > easy way.
>
> You are raising a good point. What this ultimately boils down to is the
> realization that mapping Object to Tuple is problematic.
>
> This doesn't mean that the relational model is a bad choice as a target
> model for a persistent store. On the contrary, it is probably the best
> model to use for this purpose. The problem is only the assumption that
> Object (or better: type) maps always to Tuple. Recent developments in
> relational theory suggest that it is the Domain concept ("column type")
> that should be seen as the closest equivalent to "Object Type". Refer to
> recent writings by Chris Date (books and also papers, the latter
> accessible on the Web) for the theory behind this, and why the Object <=>
> Tuple identification is a mistake.
Sure, i know about it. The main problem is inheritance and pointer members,
but i have some ideas how to deal with them. My first letter intention was just
to
describe idea.
regards,
bohdan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL's "round" lambda
"Peter Dimov" <[EMAIL PROTECTED]> writes: > Other examples that won't work correctly include: > > list(char[]) > list(char[3]) > list(void) Yeah, I had considered using function types as "lightweight type vectors", but gave up for this reason. -- 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: FW: [boost] Serialization & XML (was Serialization LibraryReview)
Robert Ramey <[EMAIL PROTECTED]> writes: > Is there a reason you sent this to me privately? >> From: David Abrahams <[EMAIL PROTECTED]> > >>I believe your assessment that some >>data structures can't be represented using XML is incorrect, and >>that's easy to prove. A serialization library which makes generation >>of XML output difficult is severely handicapped in the modern world. > > Well, I have conceded that it was preliminary. All I know about XML > is from a small book containing a concise description of XML. > > My skeptism is based on the following thought experiment: > Suppose on is given a list of polymorphic pointers, some of which > correspond to bottom node of a diamond in heritance structure > and some of which are repeated in the list and serialized > some where else as well. > > a) How would such a thing be represented in XML? I'm not an XML expert, but I know a little. It's basically a tree structure with cross-references. That means you can represent an arbitrary graph. If the pointers all correspond to the bottom node in a diamond, the problem is actually relatively easy, since you don't have to worry about ambiguous subobjects of the same type. Repetitions in the list could be handled with cross-references. Alternatively, the whole list of pointers could be handled with cross-references, and the set of objects in question could be stored in a separate XML structure. I probably haven't given enough detail here to be convincing. Some handwaving on my part is a product of not knowing somie XML details. > b) Could be loaded back to create an equivalent structure? Sure, why not? > c) Would it be useful for anything other than this serialization system? Why is that an important question? > If someone can assure me that the answers to all three of the above > is yes then it should be possible - otherwise not. Given that its > "easy to prove" these questions should be easy to answer in > a convincing way. -- 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] iterator_adaptors
Hi Herve, --On Tuesday, November 19, 2002 1:21 AM -0500 Herve Bronnimann <[EMAIL PROTECTED]> wrote: Just because I posted something about a new iterator adaptor, and I happened to take a look at the boost sandbox, that David was referring me to, I'd like to ask: is what is in the sandbox intended to replace or to complement the current ? Yes, it is intended to replace the current iterator_adaptors.hpp. The reason I am asking is that a brief reading failed to point out how what's in the sandbox provides reverse_iterator_adaptor, and all the existing ones. So am I correct in assuming that the code in the sandbox is intended to replace some/all the machinery (first 700 lines or so) of the current ? that it's internal to the implementation of the adaptors? and that we'll be able to use in the future the iterator adaptors unchanged in syntax and semantic? No, the sandbox stuff is just incomplete and very much under construction. And it will have a different public interface from the old version. Thomas, have you checked your new version in yet? Cheers, Jeremy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization to relational table
"Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message arc2ra$nhv$[EMAIL PROTECTED]">news:arc2ra$nhv$[EMAIL PROTECTED]... > "Bohdan" <[EMAIL PROTECTED]> wrote in message > arb73a$2gm$[EMAIL PROTECTED]">news:arb73a$2gm$[EMAIL PROTECTED]... > > > Recently there were talks about ditto & relational algebra libraries. > > Also there was message about stl container on disk. > > As i understand at least some of these libs require special kind > > of serialization: Object <-> Relational tuple (object-relational mapping). > > Relational algebra library (RTL) doesn't REQUIRE object-relational > mapping -- it ALLOWS it. The object can be mapped either to a field or to a > tuple -- this is up to the library user. World is so small :) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Serialization & XML (was Serialization Library Review)
Matthias Troyer <[EMAIL PROTECTED]> writes: > On Tuesday, November 19, 2002, at 06:22 AM, David Bergman wrote: > >> Hi, >> >> This is a comment from the Java corner of the world: I have, as many >> other developers using Java, implemented serialization of objects onto >> XML. It is not that hard, although there might not exist (can anyone >> verify this?) a standardized (more or less...) "C++ Object XML Format". >> >> >> There are two alternatives: >> >> 1. Use an intelligible XML Application (yes, that is what the XML folks >> call the specific XML languages, such as XHTML...), giving not only >> platform independence (which I assume the serializer module already >> achieves...) but language independence, i.e., the object or value can be >> unmarshalled, or generated, by a Python program, much in the spirit of >> the good old XDR. > > As nice as the idea is, there are C++ types that cannot be > represented in Java. Just consider templates or multiple inheritance > (from two or more base classes where neither can be represented as a > Java interface) Multiple inheritance, including diamond-inheritance is easily represented in Python. -- 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] MPL's "round" lambda
From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]> > Peter Dimov wrote: > > I wrote "I don't understand how it works even _after_ (briefly) > > looking at the code. ;-)" but then it occured to me that list(int, char, > > long, int) is a function type. > > Yep. > > > Cool trick. Cv qualifiers will probably be a problem > > They are stripped on non-class rvalues, aren't they? :(. So, basically, this > one will work: > [...] > list(int,char,long,her const) [...] > but this one won't: [...] > list(int,char,long,int const) I'd expect both to not work. list f(int, char, long, her const); and list f(int, char, long, her); declare the same function (see 8.3.5). Other examples that won't work correctly include: list(char[]) list(char[3]) list(void) and some won't work at all: list(void, int) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Forte 7 Compiler
"Ewan Brock" <[EMAIL PROTECTED]> writes: > Hello All, > > Has anyone had success in compiling boost using the Forte 7 compiler? > > When trying to compile a file even with a single include statement, > assertion errors occur: > > For example, compiling: > > #include "boost/graph/graph_traits.hpp" > > With compiler options: > > > /opt/SUNWspro/bin/CC -xarch=v9a -Kpic -mt -g -D_XOPEN_SOURCE=500 -D__EXTENSI > ONS__ -DMVE_DEBUG - > DMVE_SUN64 -DMVE_WFM -DMVE_SUN -DMVE_BOOST -DMVE_BOOST_VERSION=1290-DM > VE_STD - > DMVE_SUN_F7 -I. -I/homes/perforce/utils_install/SUN64/boost-1_29_0-SUN64.DE > BUG.F7-c main.cxx -o obj_files/SUN64.DEBUG.F7/main.o > > Gives the compiler output below: > > >> Assertion: (../lnk/init.cc, line 957) > while processing /homes/perforce/utils_install/SUN64/boost-1_29_0- > SUN64.DEBUG.F7/boost/type_traits/is_function.hpp at line 50. > > > 1. Is this occuring because I have the incorrect config > settings ? No, it's occurring because the Sun compiler is badly broken. > If so, what should these settings be for Forte 7? > > 2. Is there anything else I need to do in order to get boost > to work? You might try getting the very latest compiler patches from Sun... ...however, if that doesn't fix your problem, someone needs to implement a bunch of workarounds in Boost to avoid these errors. -- 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] MPL's "round" lambda
Douglas Gregor wrote: > On Monday 18 November 2002 05:56 am, Aleksey Gurtovoy wrote: > > If you are tired of angle brackets in your templates (no, > > it's not a TV commercial :), may be you'll like this one: > > > > typedef eval< > > count_if( > > list(int,char,long,int) > > , lambda(is_same(_,int)) > > ) > > > > >::type res; > > > > BOOST_STATIC_ASSERT(res::value == 2); > > Very cool indeed! We need to invent an award for the craziest > use of obscure language features .. to implement something useful :) > (you have my vote). Well, thank you! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost License Issues
[EMAIL PROTECTED] writes: >> From: Dave Steffen [mailto:[EMAIL PROTECTED]] > [snip] >> I've found several >> files in Boost that were lacking copyright statements, because we >> have to be so careful about this. > > I've checked the sources, and there are about 50 files lacking > copyright statements. If there are no objections, I'll update them > as appropriate (using the statements in other files of the library > in question). Could you post a list of the files first? -- 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] MPL's "round" lambda
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> Peter Dimov wrote:
>> I wrote "I don't understand how it works even _after_ (briefly)
>> looking at the code. ;-)" but then it occured to me that list(int, char,
>> long, int) is a function type.
>
> Yep.
>
>> Cool trick. Cv qualifiers will probably be a problem
>
> They are stripped on non-class rvalues, aren't they? :(. So, basically, this
> one will work:
>
> typedef eval<
> count_if(
> list(int,char,long,her const)
> , lambda(is_same(_,her const))
> )
> >::type res;
>
> BOOST_STATIC_ASSERT(res::value == 1);
>
> but this one won't:
>
> typedef eval<
> count_if(
> list(int,char,long,int const)
> , lambda(is_same(_,int const))
> )
> >::type res;
>
> BOOST_STATIC_ASSERT(res::value == 1); // error, res::value == 2
Actually I think they're stripped in function argument lists
for classes as well.
struct X {};
void f(X const) {}
void (&g)(X) = f; // proof
// really prove it's not just a conversion
template struct same;
template struct same {};
template
int cksame(T&,U&)
{
same z;
return 0;
}
int z = cksame(f,g);
> P.S. It just occured to me that with the above we finally have a way
> to write two nested template instantiations without a space between
> their closing brackets:
>
>typedef one > == typedef eval< one(another(int)) >::type
Sort of. They're not templates anymore are they?
> That one would really make a good
...or EVIL!...
> obfuscated contest's task :).
This is too funny.
--
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] MPL's "round" lambda
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >> Interesting. Like Dirk, I too am wondering what the point is, >> beyond syntactic sugar. > > What is the point of what exactly? Of yet another lambda notation? > Of round brackets? Of my post? :) > > Anyway, there wasn't much of the point besides demonstrating that >something like this is easily implementable and could have some >practical use - may be outside the MPL as well. After all, people has >been complaining about "ugly template brackets" for years ;). Actually I think you gave some pretty good arguments for this in your reply to Dirk's question. >> I notice the namespace "mpl::v2_1" in the code. > > Yes, I needed a separate scope to put things into to avoid conflicts as all > new lambda's arguments are metafunction classes, not metafunctions. Yep, they'd have to be. > It (the namespace) doesn't carry much of intent besides that :). I figured. >> Shouldn't we have completed MPL documentation before moving on to >> things like this? > > FWIW, I am not moving on to anything. I coded up the above in ~1 > hour as a proof of a sudden idea that seemed like a novel and viable > technique. Sorry, I got the impression it was going to be version 2.1 of the MPL code. -- 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] Building Boost Libraries
"Zhao,Jun (lukezhao)" <[EMAIL PROTECTED]> writes: > i have downloaded the source code of boost,but i can not to built it > under win2000 and vc.net. who can tell me the steps? thx! http://www.boost.org/tools/build Please also consider posting newbie questions on the boost-users list: http://www.boost.org/more/mailing_lists.htm#users -- 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] is_polymorphic question
> It has been reported to me that is_polymorphic gives > compile time error when T is const type and the compiler is g++. > > Is there a fix for this? Yep, filter the type through remove_cv first, is_polymorphic should really be doing this internally though, so I'll try and work up a fix. 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] MPL's "round" lambda
Peter Dimov wrote: > I wrote "I don't understand how it works even _after_ (briefly) > looking at the code. ;-)" but then it occured to me that list(int, char, > long, int) is a function type. Yep. > Cool trick. Cv qualifiers will probably be a problem They are stripped on non-class rvalues, aren't they? :(. So, basically, this one will work: typedef eval< count_if( list(int,char,long,her const) , lambda(is_same(_,her const)) ) >::type res; BOOST_STATIC_ASSERT(res::value == 1); but this one won't: typedef eval< count_if( list(int,char,long,int const) , lambda(is_same(_,int const)) ) >::type res; BOOST_STATIC_ASSERT(res::value == 1); // error, res::value == 2 It's an issue to solve indeed - thanks for reminding the rule. > but it's cool. Aleksey wins the Boost obfuscated C++ contest of the week. I am not completely sure if it's a compliment, but thanks :). Aleksey P.S. It just occured to me that with the above we finally have a way to write two nested template instantiations without a space between their closing brackets: typedef one > == typedef eval< one(another(int)) >::type That one would really make a good obfuscated contest's task :). ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Building Boost Libraries
Title: Building Boost Libraries i have downloaded the source code of boost,but i can not to built it under win2000 and vc.net. who can tell me the steps? thx!
[boost] Forte 7 Compiler
Hello All, Has anyone had success in compiling boost using the Forte 7 compiler? When trying to compile a file even with a single include statement, assertion errors occur: For example, compiling: #include "boost/graph/graph_traits.hpp" With compiler options: /opt/SUNWspro/bin/CC -xarch=v9a -Kpic -mt -g -D_XOPEN_SOURCE=500 -D__EXTENSI ONS__ -DMVE_DEBUG - DMVE_SUN64 -DMVE_WFM -DMVE_SUN -DMVE_BOOST -DMVE_BOOST_VERSION=1290-DM VE_STD - DMVE_SUN_F7 -I. -I/homes/perforce/utils_install/SUN64/boost-1_29_0-SUN64.DE BUG.F7-c main.cxx -oobj_files/SUN64.DEBUG.F7/main.o Gives the compiler output below: >> Assertion: (../lnk/init.cc, line 957) while processing /homes/perforce/utils_install/SUN64/boost-1_29_0- SUN64.DEBUG.F7/boost/type_traits/is_function.hpp at line 50. 1. Is this occuring because I have the incorrect config settings ? If so, what should these settings be for Forte 7? 2. Is there anything else I need to do in order to get boost to work? Any help will be gratefully appreciated, Ewan Brock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL's "round" lambda
David Abrahams wrote: > Interesting. Like Dirk, I too am wondering what the point is, beyond > syntactic sugar. What is the point of what exactly? Of yet another lambda notation? Of round brackets? Of my post? :) Anyway, there wasn't much of the point besides demonstrating that something like this is easily implementable and could have some practical use - may be outside the MPL as well. After all, people has been complaining about "ugly template brackets" for years ;). > I notice the namespace "mpl::v2_1" in the code. Yes, I needed a separate scope to put things into to avoid conflicts as all new lambda's arguments are metafunction classes, not metafunctions. It (the namespace) doesn't carry much of intent besides that :). > Shouldn't we have completed MPL documentation before moving on to > things like this? FWIW, I am not moving on to anything. I coded up the above in ~1 hour as a proof of a sudden idea that seemed like a novel and viable technique. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL's "round" lambda
Dirk Gerrits wrote:
> Seems very nice. But I feel to see the practical use of it.
The same as the "traditional" compile-time lambda - it allows you to write
typedef count_if<
list(int,char,long,int)
, and_(my_predicate(_), is_same(_,int))
>::type res;
instead of
typedef count_if<
list
, bind
, bind
, bind
>
>::type res;
> Is it just syntactic sugar?
The "syntactic sugar" part (round brackets) is the most innovative :), but
there are other differences/benefits as well. For one, it's much easier to
implement, partially because you don't have to fight the GCC and Borland's
"extension" of template template parameters matching rules that makes
something like this
template< typename T >
struct lambda
{
typedef T type;
};
template<
template< typename T > class F
, typename P
>
struct lambda< F >
{
typedef F type;
};
template<
template< typename T1, typename T2 > class F
, typename P1, typename P2
>
struct lambda< F >
{
typedef F type;
};
template< typename T, typename U = T > struct her;
typedef lambda< her >::type t; // error!
ambiguous. Not that the new lambda with either of those compilers, though
:).
But the main source of the original lambda's implementation complexity lies
in the fact that actually it has to treat its arguments in a much more
"intellectual" way than one might think at first. Consider, for instance,
this:
#include "boost/mpl/find_if.hpp"
#include "boost/mpl/list.hpp"
#include "boost/type_traits/is_same.hpp"
using namespace boost;
using namespace mpl;
template< typename T > struct her
{
//
};
typedef list,long> types;
// find 'her' instantiation in the list
typedef find_if< types, is_same<_, her > >::type type;
The semantics of the above is clear, and overall it seems quite harmless,
but if you compare the above with a similar-but-not-really
// find a type that is a [const] reference
typedef find_if< types, is_same<_, add_reference<_> > >::type type;
quite probably you'll see the problem; basically, there is no way how a
simple-minded lambda facility can distinguish between 'her' and
'add_reference<_>' here - unless it checks if any of the template
instantiation's arguments is a lambda placeholder, and if it does that, then
it's no more a simple minded lambda facility :). In fact, it's a pretty
complicated one.
And if it doesn't distinguish between two, then an intuitive,
"it-has-to-work"
typedef find_if< types, is_same<_, her > >::type type;
will simply fail to compile as the library will try to treat 'her' as a
metafunction (instead as a "value argument" to the 'is_same<...>' lambda
expression).
If you disable the MPL's preprocessed headers and define
BOOST_MPL_NO_LAMBDA_HEURISTIC macro, you could see it for yourself :).
Well, anyway, obviously the "round lambda" form
typedef find_if< types, is_same(_, her) >::type type;
doesn't have this problem - and the library doesn't even have to take any
special precautions for it.
Now, the last part - the semantic differences. Well, besides the above,
there is only one: the "round lambda" enables inline composition of
_metafunction classes_, not metafunctions. E.g. the 'is_same' name above
actually refers to a metafunction class:
struct is_same
{
template< typename T1, typename T2 > struct apply
: boost::is_same
{
};
};
I haven't formed the opinion whether it's a good thing or not yet :), but I
kind of like the fact that actually the two facilities are quite orthogonal,
and together they cover pretty much all the needs for inline
composition/arguments binding of compile-time invocable entities.
> And if not, could you enlighten me on the practical use? :)
Well, I just invented it yesterday and haven't even had time to think about
it since then :), but I hope the above clarifies things a little bit.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost License Issues
> From: Dave Steffen [mailto:[EMAIL PROTECTED]] [snip] > I've found several > files in Boost that were lacking copyright statements, because we > have to be so careful about this. I've checked the sources, and there are about 50 files lacking copyright statements. If there are no objections, I'll update them as appropriate (using the statements in other files of the library in question). Bjorn Karlsson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
