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
On Sun, Nov 17, 2002 at 05:36:35PM +0100, Gennaro Prota wrote:
>
> Hi Pavol, I haven't been following this thread so please forgive me if
> I'm just pointing out something stupid, or problems that you already
> know. I had a quick glance at the library and I'm a little confused at
> what is its sc
On Sun, Nov 17, 2002 at 11:20:16AM -0500, Beman Dawes wrote:
> At 04:00 AM 11/17/2002, Pavol Droba wrote:
>
> >> Have you taken a look at Darin Adler's string algorithms? See
> >> http://groups.yahoo.com/group/boost/files/string_algorithm/
> >>
> >> Do any of these have a place in your librar
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
reason to
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > From: "Eric Woodruff" <[EMAIL PROTECTED]>
> >>
> >> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> >> [EMAIL PROTECTED]">news:[EMAIL PROTECT
> Even Microsoft will soon be supporting template template parameters and
> partial specialization.
How long more MSVC6 is going to be actively used, do you think? Is there any
date/milestone since when we decide ignore non-supporting compilers for
specified features?
Gennadiy.
_
On Sunday 17 November 2002 11:01 pm, David Abrahams wrote:
> Some questions I can ask of Boost library authors that I think will
> help:
>
> 1. If we come up with a core Boost license which complies with the
>current Boost guidelines, would you be willing to consider using it
>in order to e
From: Beman Dawes <[EMAIL PROTECTED]>
>Uh... I think one of us must be misunderstanding something about XML. If
>you can represent serialization of some objects as a character based file,
>can't you turn it into dumb XML by wrapping it in
>? Perhaps you mean you don't think it is
>possibl
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 understand why you think
>this?
I have to admit I have only a cursory
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
>>
>> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
>> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> > "Peter Dimov" <[EMAIL PROTECTED]> writes:
>> >
>> > > * shared_*_cast will be renamed to sp_*_cast.
Jaakko Jarvi <[EMAIL PROTECTED]> writes:
>> The advanced features page doesn't say which namespace classes such as
>> boost::tuples::null_type reside in, AFAICT. If I just missed it, it
>> needs to be clarified.
>
> Hi Dave,
>
> It's the first sentence in the document:
>
> "The advanced features d
"Jaap Suter" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I've been a Boost user for a while, both in my pet-projects and at
> companies I worked for. However, for the first time I'm working at a
> company where we are not allowed to use Boost because of legal
> issues. I remember seeing some discussions
> > > Does anybody know how to implement type traits that will allow me to
> check
> > > whether argument type T is instance od template A. Particularly I am
> > > interested in mpl sequences. I.e.:
> > >
> > > is_instance_of::value
> >
> > Check out boost/lambda/detail/is_instance_of.hpp
>
> 1.
>
> The advanced features page doesn't say which namespace classes such as
> boost::tuples::null_type reside in, AFAICT. If I just missed it, it
> needs to be clarified.
Hi Dave,
It's the first sentence in the document:
"The advanced features described in this document are all under namespace
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 reason to know
that the translation from native types <-> XDR is faster tha
From: "Jeff Garland"
>> In general, libary code should make no presumptions as to the language
>> of the user. That means no embedded messages.
>Yes, we need to provide locale indexed message strings. No debate on that.
>Sounds like another requirement for boost::exception.
>In my view it [b
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.
I needed a universal method for rendering/de-rendering all C++ fundemental
to a series of bytes. This method had to
At 9:13 PM +0200 11/15/02, Peter Dimov wrote:
>From: "Kevin S. Van Horn" <[EMAIL PROTECTED]>
>> Peter Dimov write:
>>
>> > Throwing an exception from BOOST_ASSERT is undesired behavior. I don't
>> > want it as a standard option.
>>
>> Except that, in the case I pointed out, it sometimes is desired
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 10:19:01 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
>> >const T t(ar);
>
>> > It seems to me that your versioning infrastructure doesn't
>> > support this.
>>
>> It doesn't. It conflicted with version and added no known benefit.
hmm
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> I could use something like a std::map< weak_ptr<>, PyObject* >, ...
>
> Yes, that's the "canonical" solution if you need to associate arbitrary data
> with objects managed by shared_ptrs.
In my case it's n
> -Original Message-
> From: Arkadiy Vertleyb [mailto:[EMAIL PROTECTED]]
> > It is only when
> > I obtain and dereference (?) a relation iterator (using print, or
calling
> > begin() then dereferencing) that iteration over the tables occurs.
>
> This is true in most cases. However if y
At 12:51 PM 11/17/2002, Robert Ramey wrote:
>From: "Peter Dimov" <[EMAIL PROTECTED]>
>
>>> I'm really interested in the XDR format, not because I care about the
>>> format itself, but because others seem to use it as some sort of
litmus
>>> test for serialization libraries. Thus knowing that Robe
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 23:08:02 +0100 Matthias Troyer
([EMAIL PROTECTED]) wrote:
> It will not go wrong, but the implementation has to check for
> sizeof(short), etc., before deciding on how to serialize the short (we
> might want to change byte order, ) . On th
"Thorsten Ottosen" <[EMAIL PROTECTED]> wrote in message
02df01c28e4f$15cc5b30$76c3a8c0@nesottolap">news:02df01c28e4f$15cc5b30$76c3a8c0@nesottolap...
> - Original Message -
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> [nip]
> > In general, it is recommended practice to always assert() precon
At 01:06 PM 11/15/2002, Rozental, Gennadiy wrote:
>Unfortunately this implementation is using template template parameters
and
>partial specialization.
Should we be worrying much about compilers that don't support these
features?
Even Microsoft will soon be supporting template template paramet
> 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
> > Given that there is lots of existing practice that doesn't meet
> > your 'well-defined' standard, it seems that the only option is
> > to introduce a separate function.
>
> The wonderful thing about leaving what() implementation-defined is that it
> can be tightened to be well-defined for all
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
From: "Jeff Garland" <[EMAIL PROTECTED]>
> > Whether the right solution is to fix what() or to introduce a separate
> > function is another matter, of course.
>
> Given that there is lots of existing practice that doesn't meet
> your 'well-defined' standard, it seems that the only option is
> to in
From: "Robert Ramey" <[EMAIL PROTECTED]>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
>
> >FWIW, in my experience, XML is a better test for whether a serialization
> >library handles custom formats well. Sequence-based, header-only formats
are
> >very similar, but a reasonable XML serializer creates a
From: "David Abrahams" <[EMAIL PROTECTED]>
> I could use something like a std::map< weak_ptr<>, PyObject* >, ...
Yes, that's the "canonical" solution if you need to associate arbitrary data
with objects managed by shared_ptrs.
> ... but that would be truly awful:
>
> 1. I would need to sweep the
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> >
> > Well, my point is that if you put the check in the library, then you
> > do it once; if you don't put it there, then you do it n times. It
> > does not matter what the check is.
>
> But n can be 1 if you provide your o
Hi,
I've been a Boost user for a while, both in my pet-projects and at companies
I worked for. However, for the first time I'm working at a company where we
are not allowed to use Boost because of legal issues. I remember seeing some
discussions about the Boost licenses, but I couldn't find any de
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 library to wr
From: "Eric Woodruff" <[EMAIL PROTECTED]>
>
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > "Peter Dimov" <[EMAIL PROTECTED]> writes:
> >
> > > * shared_*_cast will be renamed to sp_*_cast.
> >
> > Why? Without rationale, this seems like a
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 library to write numbers in
> binary consistently we should also seria
Robert Ramey wrote:
1) changing the state of the stream while serializing. My implementation initialized the stream
and never contemplated that the same stream might be used for other things. That is that
serialized data might be "embedded" as part of a larger stream.
Apparently this is an issu
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > * shared_*_cast will be renamed to sp_*_cast.
>
> Why? Without rationale, this seems like a gratuitous change,
> especailly since "sp" doesn't mean m
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 10:44:33 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> they are arbitrary. but unimaginably high in my view.
I agree if we must have limits these are fairly reasonable. I don't see
the need for limits at all. It seems like premature optimisat
From: "David Abrahams" <[EMAIL PROTECTED]>
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
> > * shared_*_cast will be renamed to sp_*_cast.
>
> Why? Without rationale, this seems like a gratuitous change,
> especailly since "sp" doesn't mean much to me.
The idea is to use sp_*_cast as a consistent
Thanks, I thought I'd seen an outage notice, but when it wasn't on the main
page, I figured (wrongly) it must have been some other system I used.
At Sunday 2002/11/17 13:30, you wrote:
This is a reminder. I posted this message last week.
Regards,
Dave
X-From-Line: [EMAIL PROTECTED] Thu Nov 07 1
This is a reminder. I posted this message last week.
Regards,
Dave
--- Begin Message ---
Greetings,
This message contains vital details regarding two upcoming outages which
will affect the access of you and your developers to the SourceForge.net
site and project resources. Please read this mes
Thorsten Ottosen <[EMAIL PROTECTED]> writes:
> I'll respond to all 3 messages by this.
>
> - Original Message -
> From: "Gennaro Prota" <[EMAIL PROTECTED]>
>
>
>> On Sun, 17 Nov 2002 18:22:20 +0100, Thorsten Ottosen
>> <[EMAIL PROTECTED]> wrote:
>>
>> >Yes, but note that having both is les
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> * The default constructor and reset() will not throw; default-constructed
> shared_ptr (and weak_ptr) instances will have an unspecified use_count().
Great!
> * shared_*_cast will be renamed to sp_*_cast.
Why? Without rationale, this seems like a grat
I've been unable to contact the CVS repository for a little over an hour
now. There is nothing mentioned on sourceforge.net ... this is the error
I'm getting:
C:\Boost Releases\boost>cvs -z3 update -A -P -d 1>>update.log
cvs [update aborted]: connect to
cvs.boost.sourceforge.net(cvs.sourcefor
* The default constructor and reset() will not throw; default-constructed
shared_ptr (and weak_ptr) instances will have an unspecified use_count().
* shared_*_cast will be renamed to sp_*_cast.
* use_count_is_zero will be renamed to bad_weak_ptr.
* operator< will no longer compare pointer values
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
pretentensions to porta
In the Boost 1.29.0 release, the documentation page more/download.html
ends in mid-sentence as follows:
"Some of the individual libraries also include make and/or project files
for various compilers, but every library also"
-
Kevin S. Van
I'll respond to all 3 messages by this.
- Original Message -
From: "Gennaro Prota" <[EMAIL PROTECTED]>
> On Sun, 17 Nov 2002 18:22:20 +0100, Thorsten Ottosen
> <[EMAIL PROTECTED]> wrote:
>
> >Yes, but note that having both is less fortunate. Either we agree that
> >library writers check
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 10:19:01 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> >const T t(ar);
>
> > It seems to me that your versioning infrastructure doesn't
> > support this.
>
> It doesn't. It conflicted with version and added no known benefit.
The bene
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, 17 Nov 2002 16:28 + (GMT) Dave Harris
([EMAIL PROTECTED]) wrote:
> And of course, we cannot use it as the default way of writing
> integers because for some numbers it is less efficient (with this
> scheme the overhead can never be more than a byte).
O
To boost members interested in the serialization library.
There has been much interest in adding things to the library
which I presonally believe don't belong there. Much effort
has been expended in the design to keep the library
independent of the serialized data types and archive storage.
I bel
On Sun, 17 Nov 2002 12:53:52 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Not all preconditions are effectively checkable.
How true! :-(
>
>> Moreover, if you put the precondition in the library, you take the
>> burden away from the client
>
>No you don't. Either it's a precondition or it'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 17 November 2002 15:04, David Abrahams wrote:
> > Could we extend it by one week so that we have another weekend?
>
> Thomas Witt is the Boost Review Wizard. It's up to him. Thomas?
Fine with me.
>
> [BTW, Thomas, can we put your name and a
From: [EMAIL PROTECTED] (Dave Harris)
>>From the headers...
>>typedef unsigned char version_type; // upto 255 versions
>>namespace serialization_detail {
>>typedef unsigned short class_id_type; // upto 64k kinds
>>// of objects
>
On Sunday 17 November 2002 11:45 am, Daryle Walker wrote:
> You have poisoned (in)equality operators, because of your safe_bool
> type. Are you using a data pointer type, like "void *" that the
> IOStreams use for their safe-Boolean type? If so, you should switch to
> an even more useless type.
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>> > I haven't encountered a need to inspect the deleter yet... what
> interface
>> > are you suggesting?
>>
>> How about:
>>
>> // attempt to extract a deleter of type D
>> D* d = boost::get_deleter(p);
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>> > I haven't encountered a need to inspect the deleter yet... what
> interface
>> > are you suggesting?
>>
>> How about:
>>
>> // attempt to extract a deleter of type D
>> D* d = boost::get_deleter(p);
> 1) I made orginally made archive_exception the simplest possible, it wasn't derived
> from std::exception and and contain an enum of every exception type. It suited
> my needs and I didn't feel that std::exception added anything.
Not for you, but for clients of the library that want a reasonabl
Date: Sun, 17 Nov 2002 12:49 + (GMT)
From: [EMAIL PROTECTED] (Dave Harris)
>> "Serialization Overrides" explains this and gives a code excerpt
>> showing what one has to do to use a constructor with arguments.
>The code looks roughly like:
>ar >> a;
> t = new T(a);
>ar
Thorsten Ottosen <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> [nip]
>> In general, it is recommended practice to always assert() preconditions in
>> client code, instead of relying on in-library asserts. First, the library
> is
>> not requi
On Sun, 17 Nov 2002 18:22:20 +0100, Thorsten Ottosen
<[EMAIL PROTECTED]> wrote:
>Yes, but note that having both is less fortunate. Either we agree that
>library writers check preconditions and then
>clients don't or we agree that clients check preconditions and library
>writers don't. One reason
Date: Sun, 17 Nov 2002 10:19:23 +0100
From: Matthias Troyer <[EMAIL PROTECTED]>
>> From: Matthias Troyer <[EMAIL PROTECTED]>
>
>> Suppose you have a number on the first platform that exceeds 32
>> significant bits. What happens when the number is loaded onto
>> the second platform. Are the high o
From: "Peter Dimov" <[EMAIL PROTECTED]>
>> I'm really interested in the XDR format, not because I care about the
>> format itself, but because others seem to use it as some sort of litmus
>> test for serialization libraries. Thus knowing that Robert's library
>> handles XDR well is of interest.
>
> Oops, ambiguous parse tree.
Thx for the clarification :-)
> You are right, we can't reasonably expect that. This IMO is a defect in the
> standard. I'd definitely think twice before showing an implementation
> defined string to the user; sometimes the result looks very unprofessional.
> :-)
I
From: "Jeff Garland" <[EMAIL PROTECTED]>
On archive exception:
A short recap on the history of this:
1) I made orginally made archive_exception the simplest possible, it wasn't derived
from std::exception and and contain an enum of every exception type. It suited
my needs and I didn't feel that
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
> From: "Thorsten Ottosen" <[EMAIL PROTECTED]>
> > From: "Peter Dimov" <[EMAIL PROTECTED]>
> > [nip]
> > > In general, it is recommended practice to always assert()
preconditions
> in
> > > client code, instead of relying on in-l
From: "Jeff Garland" <[EMAIL PROTECTED]>
> > FWIW, I much prefer well-defined what() strings
("boost::pointer_conflict")
> > that I can use as keys into a message table over implementation-defined
> > descriptive messages.
>
> I don't I agree with this. While I have no issue with your desire
> to
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 04:08 AM 11/17/2002, Matthias Troyer wrote:
> >
> >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 exte
> > I am going to much prefer something that gives me some sort of real
> > clue about the nature of the problem instead of the cryptic message
> > "pointer conflict"...
>
> Only if you can read English. Don't forget that. :-)
True...
> FWIW, I much prefer well-defined what() strings ("boost::p
At 04:08 AM 11/17/2002, Matthias Troyer wrote:
>
>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
I don't know anything about Boost.Function except what I've seen
checking out the sample documentations. I have some thoughts on the ==
and != operators.
You have poisoned (in)equality operators, because of your safe_bool
type. Are you using a data pointer type, like "void *" that the
IOStre
Hi Pavol, I haven't been following this thread so please forgive me if
I'm just pointing out something stupid, or problems that you already
know. I had a quick glance at the library and I'm a little confused at
what is its scope. For instance the "is space" generalization makes in
fact functions l
In-Reply-To: <[EMAIL PROTECTED]>
Are reference-counted objects supported? If I am using my own
reference-counted class, what do I have to do to get serialisation to work
for it?
To clarify: obviously the archive needs some kind of table of loaded
objects, so that it can ensure two references to
In-Reply-To: <[EMAIL PROTECTED]>
>From the headers...
>typedef unsigned char version_type; // upto 255 versions
>namespace serialization_detail {
>typedef unsigned short class_id_type; // upto 64k kinds
>// of objects
>ty
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 16 Nov 2002 23:43:31 -0500 David Abrahams
([EMAIL PROTECTED]) wrote:
> Does anybody else feel they need more time to give this library a
> thorough going-over?
If no more time is available, I'd have to vote against including the
library in its current for
From: "Jeff Garland" <[EMAIL PROTECTED]>
> > >Why not derive a different exception from archive_exception for each of
the
> > >enum types instead of using the enum? This would be better because if
a user
> > >creates a new archive type they might need to add an exception type
which is
> > >not cur
> >Why not derive a different exception from archive_exception for each of the
> >enum types instead of using the enum? This would be better because if a user
> >creates a new archive type they might need to add an exception type which is
> >not currently possible.
>
> Wouldn't it be better for t
At 04:00 AM 11/17/2002, Pavol Droba wrote:
>> Have you taken a look at Darin Adler's string algorithms? See
>> http://groups.yahoo.com/group/boost/files/string_algorithm/
>>
>> Do any of these have a place in your library?
>
>except for regex variant which are in some way all part of the regex li
At 08:11 AM 11/15/2002, Peter Dimov wrote:
>Providing direct support in a Boost core header effectively amounts to a
>"Boost seal of approval", i.e. "we at Boost think that this is a good
>programming practice and we want to encourage its use."
While that is both correct and important in the gene
> The program test.cpp tests every aspect of the library that I can think of. I have
>included
> all the tests in one program because it is convenient to for me to develop with.
Ok. It may be sufficient once it compiles :-( Sorry I didn't actually look
at it until now. At the very least a se
From: "Thorsten Ottosen" <[EMAIL PROTECTED]>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> [nip]
> > In general, it is recommended practice to always assert() preconditions
in
> > client code, instead of relying on in-library asserts. First, the
library
> is
> > not required to have asserts, and seco
On Sun, Nov 17, 2002 at 02:46:31PM +0100, Thorsten Ottosen wrote:
> - Original Message -
> From: "Pavol Droba" <[EMAIL PROTECTED]>
>
> > > Your example would become
> > >
> > > if ( lower_cased( trimmed( s ) ) = "ok" )
> > >
> >
> > This naming sounds good enough, just I'm not sure if such
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
[nip]
> In general, it is recommended practice to always assert() preconditions in
> client code, instead of relying on in-library asserts. First, the library
is
> not required to have asserts, and second, the earlier you catch
pr
From: "David Abrahams" <[EMAIL PROTECTED]>
> > I haven't encountered a need to inspect the deleter yet... what
interface
> > are you suggesting?
>
> How about:
>
> // attempt to extract a deleter of type D
> D* d = boost::get_deleter(p);
> if (d)
> {
> // that was the delete
From: "David Abrahams" <[EMAIL PROTECTED]>
> > I haven't encountered a need to inspect the deleter yet... what
interface
> > are you suggesting?
>
> How about:
>
> // attempt to extract a deleter of type D
> D* d = boost::get_deleter(p);
> if (d)
> {
> // that was the delete
Matthias Troyer <[EMAIL PROTECTED]> writes:
> 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
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>> In Boost.Python, I am going to start using custom deleters to enable
>> me to produce shared_ptr from any Python object which contains a T,
>> while keeping the Python object alive. I can't believe I didn't t
- Original Message -
From: "Pavol Droba" <[EMAIL PROTECTED]>
> > Your example would become
> >
> > if ( lower_cased( trimmed( s ) ) = "ok" )
> >
>
> This naming sounds good enough, just I'm not sure if such a difference
>between
> two variants would not make the code less readable. Alfter
From: "David Abrahams" <[EMAIL PROTECTED]>
> In Boost.Python, I am going to start using custom deleters to enable
> me to produce shared_ptr from any Python object which contains a T,
> while keeping the Python object alive. I can't believe I didn't think
> of this earlier, and I want to thank Pete
From: "Dan Gohman" <[EMAIL PROTECTED]>
[...]
> Documentation:
>
> set
>
> void set(T * p); // never throws
>
> Stores a copy of p, which must have been allocated via a C++ new
> expression or be 0. Behavior is undefined if the stored pointer
> is not 0.
Rejected, sorry. :-) Introducing undefined b
In-Reply-To: <[EMAIL PROTECTED]>
On Sat, 16 Nov 2002 22:50:23 -0800 Robert Ramey ([EMAIL PROTECTED]) wrote:
> A default constructor is not required. The reference section
> "Serialization Overrides" explains this and gives a code excerpt
> showing what one has to do to use a constructor with argu
Terje, this is my last reply here because we are widely off-topic. Ah,
is your mail server up? I repeatedly get delivery status notifications
(Status: 5.1.1: bad destination mailbox address).
You wrote:
>> >Much later,
>> >the ANSI/ISO C++ committee had a stream of formal definition experts
>> >e
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 have a numbe
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
On Sat, Nov 16, 2002 at 04:43:53PM -0500, Beman Dawes wrote:
> At 11:58 AM 11/15/2002, Pavol Droba wrote:
> >Hi Boosters,
> >
> >I have developed a set of various string manipulating functions into a
> >string_algo lib.
>
> Pavol,
>
> Have you taken a look at Darin Adler's string algorithms?
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?
Robert Ramey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
98 matches
Mail list logo
