Dear Robert,
I'm also impressed by how much effort you have invested and am working
myself through the documentation now. I will have a number of questions
regarding your resolution of some of my concerns from the last review,
and wonder whether I should send you the list in private or openly o
Dear Boosters,
Since some of the applications and libraries we plan on releasing soon
rely on Boost features and bugfixes that are in the CVS but not in
Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0
release? Since we would prefer to base our released software on a Boost
rel
On Friday, August 8, 2003, at 12:21 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
Dear Boosters,
Since some of the applications and libraries we plan on releasing soon
rely on Boost features and bugfixes that are in the CVS but not in
Boost 1.30.[012] I wonder wh
On Tuesday, July 29, 2003, at 07:13 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
Finally in the new version of graph_properties.hpp there is an #ifdef
that spans three lines (line 165). Could some please make this into a
one-line #ifdef. (patch4 is a crude version
Dear Boosters,
We have found several problems with Boost when porting our codes to IBM
Power4 systems and to several Linux variants:
The first two patches (patch1, patch2) that are attached define some
missing static const data members that were declared in the Boost
random library but not def
Dear Boosters, dear Jens,
After some debugging I realized another bug in the new version of the
Boost random number library. uniform_real has the following operator():
result_type operator()(Engine& eng) { return eng() * (_max - _min) +
_min; }
This does not work if the underlying engine doe
Dear Jens, dear Boosters,
Some of the new distributions in the Boost random library no longer
work with floating point based generators. Could Jens or somebody fix
that? I myself am reluctant to provide a fix.
Here is a test program that fails to compile now:
#include
int main()
{
boost::l
Dear Boosters,
In trying to port my codes and boost to an IBM Regatta (Power-4)
massively parallel machine, I encountered compilation problems like the
following that I cannot solve when compiling with IBM's xlC C++
compiler. Can anyone provide some insight or should I forget about the
IBM com
On Tuesday, July 15, 2003, at 07:31 AM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
Sorry, Here is an example that shows the problem in a simple case:
#include
#include
int main()
{
boost::adjacency_list
boost::no_property, boost::no_property, boost::no_pr
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
I now get the following compile-time error on MacOS X using g++ v.
3.1:
/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
sizeof'
applied to incomplete t
On Monday, July 14, 2003, at 11:04 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
I do not have documentation of the new version of the iterator
adaptors (either my CVS checkout is messed up or maybe it is not in
the CVS yet)
http://tinyurl.com/gv90
http://tinyurl.co
Hi,
I now get the following compile-time error on MacOS X using g++ v. 3.1:
/Users/troyer/src/boost/boost/iterator/iterator_adaptor.hpp:282:
`sizeof'
applied to incomplete type `boost::STATIC_ASSERTION_FAILURE'
Can anybody help?
Matthias
___
Unsu
Dear Boosters,
Since the update of the iterator adaptor library broke boost
multi_array (or at least my CVS version of it), I tried to fix it and
came up with the patch below which makes my codes compile again. Since
I do not have documentation of the new version of the iterator adaptors
(eith
Thanks Beman
it now works again and I hope that multi_array will also be fixed soon
Matthias
On Monday, July 14, 2003, at 03:31 AM, Beman Dawes wrote:
At 09:40 PM 7/12/2003, Jeremy Maitin-Shepard wrote:
>Matthias Troyer wrote:
>> Dear Boosters,
>>
>> After a recent cvs u
Dear Boosters,
After a recent cvs update I can no longer compile the boost filesystem
library:
/Users/troyer/src/boost/boost/filesystem/path.hpp:98: `
default_iterator_policies' undeclared in namespace `boost'
Is my CVS checkout in disarray since I can nowhere find
default_iterator_policies,
I would be interested,
Matthias
On Thursday, June 19, 2003, at 03:22 AM, Paul Vanlint wrote:
A couple of years ago I wrote a library module which provides a
reasonably
efficient way of handling with disjointed buffers and treating them as
a
single contiguous block for extracting data.
It was
On Wednesday, May 28, 2003, at 01:08 PM, John Maddock wrote:
The undefind reference comes from posix_api.o . I guess that
s_match_vtable is not used in that file.
You bet it is, you would get the unresolved external if it wasn't
being used
:-)
On MacOS X using g++ version 3.3 in addition to the
On Tuesday, May 27, 2003, at 05:44 PM, John Torjo wrote:
- does not work for wchar_t. While this might seem silly, it's not,
since
VC allows for a TCHAR* command line string.
I have to consider this. An obvious approach would be to add template
parameter to every class, telling which char type to
In my opinion this proposal should be split into two parts:
1) an efficient container for short fixed size vectors and matrices and
operations on them, similar to TinyVector in Blitz++. This might
be part of ublas.
2) a geometry library built on this TinyVector
Matthias
__
Dear Boosters,
After a cvs update I am having probles compiling cregex.cpp on an Intel
Linux platform with the KC compiler. The problem seems to be an
ambiguity in a call to destroy(..). While this is probably a bug in the
KCC compiler, I would appreciate a workaround (e.g. changing the name
o
On Thursday, May 8, 2003, at 10:12 AM, Kresimir Fresl wrote:
Matthias Troyer wrote:
That's a good point. I have prepared a version separate from
functional.hpp and posted it on our web server:
http://www.comp-phys.org/software/function_objects/
Shouldn't the default type of the
Dear Boosters,
Mario Rueti, a student in my group, needed and wrote the following
function objects which seem to be missing in the standard library (only
arithmetic and logical operations seem to be defined as function
objects). Since these might be of more general interest we wonder if
they m
On Friday, March 21, 2003, at 09:05 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
When trying to compile the filesystem library with KAI C++ we
encounter a problem in
boost/type_traits/is_base_and_derived.hpp
Uh, wait...
It seems that the workaround is needed also f
238 here be changed at least to 243?
Best regards,
Matthias Troyer
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Can you elaborate as to what the difference between Box-Muller and the implemented method is? As far as I understand Box-Muller it is just the implemented algorithm.
On Wednesday, February 12, 2003, at 09:30 AM, Lapshin, Kirill wrote:
Hello all,
We've noticed that normal_distribution using po
On Wednesday, February 5, 2003, at 04:52 PM, Toon Knapen wrote:
On Wednesday 05 February 2003 10:27, Matthias Troyer wrote:
After we get the regrssion tests to work, there will be a special
challenge for ublas or MTL-3: Calling the BLAS routine where
appropriate will be essential in getting any
Hi Dan,
Thanks for your input regarding the Cray X1. My efforts to port my
codes to Cray vector machines are aimed at using an X1 in the future,
and I use our SV1 machines at this time mainly to sort out problems,
to vectorize my codes and for first tests.
On Wednesday, February 5, 2003, at 0
On Wednesday, February 5, 2003, at 08:22 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 2:04 PM [GMT+1=CET],
Matthias Troyer <[EMAIL PROTECTED]> wrote:
Actually there were two problems. One was the one you mentioned above.
The other was that we needed either a masking to 32 b
On Wednesday, February 5, 2003, at 04:24 PM, Dave Abrahams wrote:
On Wednesday, February 05, 2003 10:11 AM [GMT+1=CET],
Matthias Troyer <[EMAIL PROTECTED]> wrote:
I am looking into it but already have a conjecture. When using signed
64 bit integers the Cray compiler (with optimization
On Wednesday, February 5, 2003, at 11:42 AM, Samuel Krempp wrote:
Le mer 05/02/2003 à 10:27, Matthias Troyer a écrit :
It seems that on all Crays the macros CRAY and cray are defined. If
one
wants to be machine specific, we got this information recently:
On Wednesday, January 22, 2003, at
On Wednesday, February 5, 2003, at 02:56 PM, Jeff Garland wrote:
The lack of support of standard library functions associated with
long long is a problem on other platforms and other functions (eg:
std::abs). This has been a headache for me using the int64_t in
date-time.
So I presume that the
On Wednesday, February 5, 2003, at 12:55 AM, Beman Dawes wrote:
At 05:06 PM 2/4/2003, Matthias Troyer wrote:
>I have run the regression tests on a Cray SV1 system using the Cray
C++
>3.6 compiler and posted the results on
>http://www.comp-phys.org/boost/cs-sn9626.html
Why don'
Dear Boosters,
I have run the regression tests on a Cray SV1 system using the Cray C++
3.6 compiler and posted the results on
http://www.comp-phys.org/boost/cs-sn9626.html
I have not looked at all the problems yet and will do so when I find
time. For now I have posted it just in case that some
On Monday, February 3, 2003, at 04:37 PM, Beman Dawes wrote:
At 03:10 AM 2/3/2003, Matthias Troyer wrote:
>prompt$
>../tools/regression/build/bin/process_jam_log/cray/release/
>process_jam_log
>Usage: bjam [bjam-args] | process_jam_log [locate-root]
> locate-root is the s
On Monday, February 3, 2003, at 06:20 PM, Emily Winch wrote:
On Mon, 2003-02-03 at 08:02, Matthias Troyer wrote:
Yes, Emily Winch was working on this, and I thought she was going
to
submit to boost. The following URL has a paper she wrote about
this.
http://www.oonumerics.org/tmpw01
On Sunday, February 2, 2003, at 05:36 PM, Beman Dawes wrote:
At 05:37 PM 2/1/2003, Matthias Troyer wrote:
>
>On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote:
>
>> At 12:39 PM 2/1/2003, Matthias Troyer wrote:
>>
>> >< cat regress.log | $p
>>Yes, Emily Winch was working on this, and I thought she was going to
>>submit to boost. The following URL has a paper she wrote about this.
>>
>>http://www.oonumerics.org/tmpw01/schedule.html
I can't access that file. Is there a server problem or has it moved?
On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote:
At 12:39 PM 2/1/2003, Matthias Troyer wrote:
>< cat regress.log | $process_jam_log
>---
> > cat regress.log | $process_jam_log $boost_root
>...
>Finally, I wonder why I need the sixth change. How doe
On Saturday, February 1, 2003, at 07:07 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
First the (maybe stupid) question: how can I disable
the building of shared libraries when using bjam?
Shared libraries do not seem to exist on the
vector-Crays and I would l
Dear Boosters,
Since we got to work jam on the Cray, found an optimizer bug when
compiling regex with -O3 that we will report to Cray and got regex to
compile at -O2, I am now running the regression tests.
While they are running I want to ask a question about building and post
a patch/questio
Hi,
I have now run the regression tests on a Cray SV1 but it seems there is
still a problem in the postprocessing stage. I get output like:
generating html tables:
Using /u/ph/troyer/boost/status/bin/bind_test.test to determine
compilers
Missing jam_log.xml in target
"/u/ph/troyer/boost/status
On Wednesday, January 22, 2003, at 07:56 PM, Matthias Troyer wrote:
Dear Boost Jamers,
Our local Cray adminstrators (Bruno Loepfe from ETH and Olivier Byrde
from Cray) found a bug in the boost jam sources. it is in the file
hash.c:
keyval = keyval * 2147059363 + *b
On Thursday, January 23, 2003, at 07:14 PM, Dan Gohman wrote:
Hi Matthias,
The reason for special-casing the Cray X1 here is so that int_fast16_t
isn't defined to be short, as short has performance penalties
associated
with it on this platform.
Hi Dan,
I missed that point. Yes, you are right
Hi Dan,
I don't think this will be needed since on the X1 USHRT_MAX should be
0x, and thus the default version will work. Note that the patch for
the SV1 and other Crays that I submitted checks for USHRT_MAX being
0x and thus does not apply on the X1 anyways.
On another note, I got
Dear Boost Jamers,
Our local Cray adminstrators (Bruno Loepfe from ETH and Olivier Byrde
from Cray) found a bug in the boost jam sources. it is in the file
hash.c:
char *b = (*data)->key;
int keyval;
.
keyval = *b;
while( *b )
keyval = key
Thank you very much!
Now the Cray people just need to find the jam problem, and I will be
able to test more.
On Wednesday, January 22, 2003, at 01:13 PM, John Maddock wrote:
While I am still working on these three issues, I could solve the
problem with cstdint.hpp. and have attached a context d
Matthias Troyer <[EMAIL PROTECTED]> writes
I tried to run the boost regression test but the first
problem I encountered is that jam does not seem to work
on a Cray machine:
athos:> sh ./build.sh cc
...
./bootstrap.cc/jam0 -f build.jam --toolset=cc --toolset-root=
./build.sh[3]: 48150
On Tuesday, January 21, 2003, at 07:43 PM, Beman Dawes wrote:
At 12:23 PM 1/21/2003, Matthias Troyer wrote:
>I could get jam to compile and could start the regression tests with a
>couple of patches to Makefiles and scripts. Now I am stuck, since for
>each library the regression te
I could get jam to compile and could start the regression tests with a
couple of patches to Makefiles and scripts. Now I am stuck, since for
each library the regression tests abort with an error message such as:
*** Error: std::runtime_error: boost::filesystem::directory_iterator
constructor: "
Both CRAY and cray are defined.
I have also heard that future Cray compiler versions will have a 16-bit
short type, albeit with performance penalties.
Matthias
On Tuesday, January 21, 2003, at 01:10 PM, John Maddock wrote:
While I am still working on these three issues, I could solve the
probl
This did not help but I'm getting closer. I don't have a full trace
back but the debugger tells me that it happens in line 99 of file
hash.c:
char *b = (*data)->key;
Since the problem vanishes when I turn off optimization (-O0), I'm not
sure whether it is a compiler or jam bug. I will forward
On Monday, January 20, 2003, at 05:38 PM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
Floating exception (core dumped)
Can you post a printout of your environment variables, starting with
MANPATH?
Here are all the variables:
USER=troyer
LOGNAME=troyer
HOME
On Monday, January 20, 2003, at 04:51 PM, David Abrahams wrote:
One other thing worth checking if you can't get a stack trace easily:
./bootstrap.cc/jam0 -d12
You may get enough useful output for us to track down the problem.
Here is is. I will send a stack trace as soon as I can get it. I ho
On Monday, January 20, 2003, at 04:27 PM, Toon Knapen wrote:
I tried to run the regression test but the first problem I encountered
is that jam does not seem to work on a Cray machine:
And what happens if you use make directly ?
Same problem if I use make, jam compiles but then crashes
Ma
On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote:
If you can test and supply patches they would be much appreciated,
come to
that, I don't suppose you would like to volunteer to regularly run the
regression tests on that platform would you (no problem if you can't
though)? Testing
I still have three problems with Cray C++ v. 3.6, but got some parts to
compile. They are:
i) a problem with template instantiation - here it seems that the
compiler might not be correctly installed on our system and I will talk
to the Cray engineers.
ii) static assertions do not work
iii) in so
On Saturday, January 18, 2003, at 10:33 PM, David Abrahams wrote:
ii) the fast vector units do not help anything for compiling the code.
Just one question: why the heck don't they make a cross-compiler which
runs on a machine better-suited to compilation?
They have that, but it costs extra m
On Saturday, January 18, 2003, at 07:36 PM, Daniel Yerushalmi wrote:
I'll try to do it at least once to see which parts of boost we can use,
and see how much CPU time this gobbles up. If it is not too much, I
will talk to our sysadmins if they would allow me to do it about once a
month. I don't
On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote:
1.) it seems that Cray C++ with the "-h conform" option, which
enforces
strict standard conformance does not compile this code in
boost/filesystem/operations.hpp
class directory_iterator
: public boost::iterator< std::input
Dear Boosters,
All of our codes are now built on top of boost. Since we might use Cray
vector computers more in the future (finally they provides a
standard-conforming C++ standard library in release 3.6) we started
porting our codes to the Cray. I did not run the full test suite, but
just tri
A couple more questions.
I'm afraid I don't have the time or expertise to create a full C++
compiler (tho it would be interesting to try using Spirit). If I were
to
base a reflection framework on PDT, its parser and toolset comes as
binaries for the following platforms:
alpha
apple
hp9000s700
li
On Wednesday, December 18, 2002, at 05:03 PM, Robert Ramey wrote:
From: Matthias Troyer <[EMAIL PROTECTED]>
template
void save(Archive &ar, T& t)
{
ar << member1;
...
}
Here we have a problem as far as I can see: if the class is
polymorphic, how can I serialize
On Wednesday, December 18, 2002, at 02:24 AM, Robert Ramey wrote:
From: Matthias Troyer <[EMAIL PROTECTED]>
I would like to make a comment here: our aim was just to achieve
portability between all different UNIX variants. We have about ten
different UNIX architectures around, but actua
On Wednesday, December 18, 2002, at 01:57 AM, Robert Ramey wrote:
From: Ihsan Ali Al Darhi <[EMAIL PROTECTED]>
I have a question for you.
Do you think that the serialization library should save exceptions?
I don't know if the question is for me but I'll respond anyway.
I can't imagine wh
Dear Robert,
thanks for your comments to my posting
On Tuesday, December 17, 2002, at 06:58 PM, Robert Ramey wrote:
From: Matthias Troyer <[EMAIL PROTECTED]>
5) "Versioning": [snip]
overhead for version number is 1 or 2 bytes per class definition.
tracking the classes so f
On Tuesday, December 17, 2002, at 05:52 PM, Robert Ramey wrote:
Second, in terms of Serialization, I'm willing to create a portable,
efficient binary archiver based on CDR (the format used by CORBA).
Since
I'm lazy, I will probably steal most of the code from ACE/TAO
(http://www.cs.wustl.edu/~
On Monday, December 16, 2002, at 06:41 PM, Beman Dawes wrote:
At 12:12 PM 12/16/2002, Glen Knowles wrote:
>I think what he might be asking for is something like:
>
>make /my/full/path relative to /my/base/dir produces ../../full/path
Ah... Thanks...
The practical problem is determining if two
Dear Serialization-Boosters,
In the past weeks I have been to busy at work to contribute much to the
serialization debate, but I managed to find some time now. It seems to
me that the discussion is drifting too far into semantic debates and I
would like to refocus by proposing to split the prob
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Hi Beman,
In a couple of hours I changed all our codes that depend on
boost::filesystem. Although I did not perform a through review, I had
no problem using the library. I found
On Saturday, November 30, 2002, at 02:06 AM, David Abrahams wrote:
Matthias Troyer <[EMAIL PROTECTED]> writes:
In any case the library user should be reminded that short, int and
long are never portable
Of course they are perfectly portable!
I don't understand how you mean that
On Friday, November 29, 2002, at 06:32 PM, Robert Ramey wrote:
Two suggestions *I think* have been made.
1) that the serialisation library recommends to users who want
portable
archives, should use the boost::int*_t types instead of short, int,
etc.
This would only be applicable to binary a
On Thursday, November 28, 2002, at 07:42 PM, Iain K.Hanson wrote:
But C 99 standardised the int*_t types and in anticipation that C++ 0x
might do the same, boost has them in the integer library ( cstdint.hpp
).
Two suggestions *I think* have been made.
1) that the serialisation library recomme
On Wednesday, November 27, 2002, at 06:05 PM, Kevin Lynch wrote:
Michael Walter wrote:
If a library user wants his archives to be portable he has to use
int8_t, int16_t, etc..
I don't remember seeing this pointed out, so forgive me if I just
missed it or am just stating the obvious, but:
T
On Tuesday, November 26, 2002, at 08:32 PM, Michael Walter wrote:
DG> Robert Ramey wrote:
We should discuss whether to use short, int, long ... as the
primitive
types or int8_t, int16_t, int32_t, int64_t. The latter makes it
easier
to write portable archives, the former seems more natural. I
Robert,
As you view binary archives as an extension to a basic serialization
library, which I can submit but which can be kept separate from the
core functionality - so can the polymorphic pointer
registration/serialization be viewed as an extension to a basic
serialization library that provid
I was referring to one virtual function call for EVERY element in a
large vector as opposed to only one virtual function call for the whole
vector.
Matthias
On Tuesday, November 26, 2002, at 09:39 AM, Keith Burton wrote:
For the ignorant like me , would you care to explain under what
circumsta
On Tuesday, November 26, 2002, at 03:01 AM, Robert Ramey wrote:
Date: Mon, 25 Nov 2002 10:41:17 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
I guess this should be changed to:
#ifdef BOOST_HAS_MS_INT64
virtual basic_iarchive & operator>>(int64_t & _Val) = 0;
vi
* A serialization of bool is missing - easy to fix
I don't understand what you mean. basic_[i|o]archive contain:
Sorry, I missed that because it is separate from the other virtual
functions and not implemented in the b[io]archive class on which I
based my XDR implementation.
* The code wil
On Monday, November 25, 2002, at 05:22 AM, Robert Ramey wrote:
Date: Sun, 24 Nov 2002 20:39:03 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
you seem to have misunderstood that: a function
void basic_oarchive::write_array(double* p, std::size_t n)
will work for ALL contiguous d
On Sunday, November 24, 2002, at 06:40 PM, Robert Ramey wrote:
5.5 "Superfast I/O"
There have been requests to add more primitive virtual functions to
basic_[i|o]archive in order to permit increased efficiency.
Specifically,
the idea is to add for each primitive type a virtual function to per
After spending more time with the serialization library, implementing
an archive
for the XDR format and considering how I could read my old archive
files using this
library instead of my own one, I can now give a more detailed review of
the
serialization library. I will keep those parts that
I have started using the boost filesystem library in our application
codes and encountered a problem that could be solved by adding either
of the three functions
bool is_relative() const;
bool is_absolute() const;
void make_absolute();
to the path class.
Let me motivate this by an example: if
On Saturday, November 23, 2002, at 01:34 AM, Augustus Saunders wrote:
[ lots of very interesting comments deleted]
One last thought on the
multiple format problem: it may be wiser to standardize all
serialization on XML and rely on XSLT to transform into all the
different formats we might want
On Friday, November 22, 2002, at 10:07 PM, Dave Harris wrote:
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 19 Nov 2002 08:09:13 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
The only solution which comes to my mind is additional virtual
functions for writing blocks of primitive types,
On Friday, November 22, 2002, at 03:33 PM, Wesley W. Terpstra wrote:
* Some approaches, including XML, allow a practically unlimited
number of
different ways to represent the same data. The user rather than the
serialization library should choose the particular design.
XSLT will allow this. As
On Wednesday, November 20, 2002, at 01:42 PM, Gennadiy Rozental wrote:
[Issue 3] Library seems to hardcode important part of functionality
that
users may want to overwrite. Here I refer in most part to
archive/object
preamble.
Major [Issue 3]: Submitted library is somewhat limited in a means
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 submissi
On Tuesday, November 19, 2002, at 04:32 AM, Robert Ramey wrote:
Date: Mon, 18 Nov 2002 08:19:28 +0100
From: Matthias Troyer
overriding the very general template definiations above for this
special case would result in
template
inline boost::basic_iarchive & operator>>(boost::basi
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 s
On Monday, November 18, 2002, at 02:30 PM, Yitzhak Sapir wrote:
I think taking out the pointer facility into a separate class would be
better design. By this I mean, that register_type<> and the logic for
identifying and maintaining pointers would be in a separate class from
the archive. The
On Monday, November 18, 2002, at 01:04 PM, Jeff Garland wrote:
Let me give one example: we store parameters in a class
typedef std::map ParameterMap
...
If instead of typdef-ing ParameterMap as a std::map, I derive
ParameterMap from it then I can easily write a save and load function
to write
On Monday, November 18, 2002, at 05:54 AM, Robert Ramey wrote:
From: "Jeff Garland" <[EMAIL PROTECTED]>
If there are technical reasons why the library cannot be extended to
do this than I would definitely vote to reject. It sounds like that's
what you and Robert are saying, but I don't unders
There seems to be a confusion regarding XML serialization.
An XML archive could easily be done by wrapping every output of a
primitive type in tags, e.g. int could be wrapped in 32434
, et.c. Thus XML output is no problem at all. Of course that's
not very useful. However the user can wrap all
On Monday, November 18, 2002, at 04:46 AM, Robert Ramey wrote:
From: Matthias Troyer <[EMAIL PROTECTED]>
I believe we all agree that portable binary archive formats are
essential in addition to the text based one.
I will be very curious to see timings on this. There is no apriori
We use both XML and binary XDR formats for serialization in our
applications: XML for short files and for meta-information, files in
XDR and/or HDF5 for large data sets. While I can imagine a
serialization of a class into XML as part of a serialization library
like the one proposed, I cannot ea
On Sunday, November 17, 2002, at 10:49 PM, Dave Harris wrote:
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 10:19:23 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
It can cause troubles, since for my portable codes I use int64_t or
int32_t to be portable. In order for the libr
On Sunday, November 17, 2002, at 07:08 PM, Robert Ramey wrote:
Date: Sun, 17 Nov 2002 10:19:23 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
It is mentioned in several places in the code, docs and in this list
that the native binary archive derivations have absolutly no
pretentensi
On Sunday, November 17, 2002, at 07:22 AM, Robert Ramey wrote:
From: Matthias Troyer <[EMAIL PROTECTED]>
Imagine I use a platform where long is
64-bit, write it to the archive and then read it again on a platform
where long is 32-bit. This will cause major problems.
Suppose you
On Sunday, November 17, 2002, at 05:43 AM, David Abrahams wrote:
Does anybody else feel they need more time to give this library a
thorough going-over? I think we could afford to extend the review for
a few more days. I would especially be willing to do so if it would
allow for enough discussion
Before coming to my detailed review I would like to thank Robert for
all his work and for contributing it to Boost.
I want to start with a general comment about text vs. binary archives.
While a text archive is nice to look at, and can also be compressed
after writing to save disk space there
100 matches
Mail list logo
