David Abrahams wrote:
> > Done.
>
> What's done?
Sorry, seems, that I've stripped of from my mail all of the useful
information :-)
I've added a new file boost/iterator_adaptors.hpp to the boost-sandbox
CVS, which contains nothing more, than
#define BOOST_ITERATOR_ADAPTORS_VERSION 0x0200
#incl
I've occasionally read that the std::auto_ptr system was changed in an
update document, due to some problems in the standard's specification.
Is this true? If so, is there a place where I can read the adjusted
system?
(I want to finally add an array-variant to Boost, and I want to make it
cl
Is it OK to make these adjustments to our main CVS?
1. The base-from-member template forwards constructor arguments up to
3. I want to extend it to around 10. (I saw some code that used a
custom BFM class because he needed 5 forwarded arguments.)
2. From discussions in the Users mailing list,
On Thursday, June 12, 2003, at 6:27 PM, Beman Dawes wrote:
At 01:31 PM 6/12/2003, Daryle Walker wrote:
[SNIP]
Is it possible to override this and use "." or ".." as regular object
names?
No. Likewise there is no escape mechanism that allows you to include
"/" in a name.
There are a bunch of rea
The status table at
http://boost.sourceforge.net/regression-logs/cs-win32.html was generated
with an experimental version of the status table software.
It adds a new possible result, "note", which is in addition to the usual
"pass", "fail", or "warn" results.
As a trial of the feature, John Ma
I used sprit to parse XML as part of my interest in serialization.
This is an incredible work. It took me a couple of days of
study. One day to adapt one of the samples to parse the XML
needed. One day to deal with a couple of rough edges in the
package. It takes forever to compile a parser
[EMAIL PROTECTED] (Hartmut Kaiser) writes:
>> OK, that seems reasonable. Libraries can check to see if
>> BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different
>> code in that case.
>
> Done.
What's done?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_
At 09:01 PM 6/9/2003, Dave Gomboc wrote:
>> Instead of dropping elements when the buffer is full, we might also
>> consider waiting or throwing a failure.
>
>I consider "dropping elements" to be surprising behaviour. If there's no
>policy stuff, then either decide that it will throw, or leave wha
At 07:50 PM 6/10/2003, iad929 wrote:
>I am facing a problem in downloading Boost from SouceForge. I tried all
the
>mirror sites but nothing happens. When I used a program like GetRight
(that
>can be used for downloading), it produces a message saying that the
library
>doesn't exist.
Whatever t
At 09:25 PM 6/9/2003, Gennadiy Rozental wrote:
>
>"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> Hello,
>>
>> Boost.Test does not currently honor BOOST_DISABLE_WIN32. The attacched
>patch
>> fixes it. Can someone review & apply this patch?
>>
>> Thanks
>> Giovanni
At 11:19 AM 6/8/2003, David Abrahams wrote:
>"John Maddock" <[EMAIL PROTECTED]> writes:
>
>> A while ago Beman produced header dependency tables, unfortunately
these
>> began to get rather complicated and so were dropped, I've placed some
>> alternative tables here:
>>
>> Boost header dependencies
Reece Dunn wrote:
Hamish Mackenzie wrote:
How do you feel about having a node_reference instead.
What are the access differences? I.e. could you use '.' to access
attributes/methods as opposed to '->'?
yes of course, that's the whole point: it's a wrapper around a C
pointer, endowed with all t
Hamish Mackenzie wrote:
How do you feel about having a node_reference instead.
What are the access differences? I.e. could you use '.' to access
attributes/methods as opposed to '->'?
// libxml2
class node_reference
{
private:
xmlNodePtr node_;
};
[snip]
boost::xml::dom::node_reference mynode
On Fri, 2003-06-13 at 19:39, Reece Dunn wrote:
> >>This would, however, allow the implementation to be adapted to when memory
> >>management needs to be used and to switch between different management
> >>policies for the various implementations.
>
> >Can you elaborate ?
>
> Sure. In the libxml
Reece Dunn said:
> Beman Dawes wrote:
>
>>I gave that some consideration at one time, but the full URI spec
>> (http://www.ietf.org/rfc/rfc2396.txt) covers so much that is totally
>> outside the scope of a filesystem library that it really seems an
>> over-generalization to try to included it as p
David Abrahams wrote:
> > What about re-introducing the boost/iterator_adaptors.hpp file:
> >
> > #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000
> > #include
> >
> > This would allow for some version tracking and a smooth
> migration path
> > for those libraries, willing to support both, the new
On Fri, 2003-06-13 at 18:53, Stefan Seefeld wrote:
> > Maybe we do need to allow the use of _private in higher level layers.
>
> I don't think that's a good idea, in particular because it's to tightly
> coupled to a particular implementation. We could allow a 'payload' for
> nodes (possibly a temp
Beman Dawes wrote:
I gave that some consideration at one time, but the full URI spec
(http://www.ietf.org/rfc/rfc2396.txt) covers so much that is totally
outside the scope of a filesystem library that it really seems an
over-generalization to try to included it as part of filesystem::path. The
Stefan Seefeld wrote
I also like the
xml::dom::document document = xml::dom::parse_file(argv[1]);
style usage. Also:
xml::dom::element e = doc.documentElement();
xml::dom::node n = e;
This is just my preferred style/usage, and does not have to be adopted.
you mean you vote for the 'nodes-a
Hamish Mackenzie wrote:
Yes, I can see that, for the xml node types. But for that we don't even
need anything but a single 'node_proxy' class (with a 'type()' method
returning an enum).
True.
Though it might be useful in the next layer of the interface. If you end
up with another proxy type tha
On Fri, 2003-06-13 at 16:11, Stefan Seefeld wrote:
> well, it looks like a mix of things. What you are doing, essentially,
> is wrapping a polymorphic 'do_something' method around a non-C++
> type system, i.e. the real method invocation is done with a 'type()'
> discriminator.
Yes.
> Yes, I can s
At 09:54 PM 6/12/2003, Glen Knowles wrote:
>From: Beman Dawes [mailto:[EMAIL PROTECTED]
>>There are a bunch of reasons - but particularly it would be creating
>>names that will just be rejected by many (or even most) modern operating
>>systems. What would be the point of that? It is the same as
Reece Dunn wrote:
Any node can define namespaces:
...
...
...
so namespace lookup would propagate along the parents of each node until
a matching namespace is found. This would mean that each node must store
a (smart) pointer to a namespace mapping, in order to facilitate
Glen Knowles wrote:
From: Beman Dawes [mailto:[EMAIL PROTECTED]
>There are a bunch of reasons - but particularly it would be creating
>names that will just be rejected by many (or even most) modern operating
>systems. What would be the point of that? It is the same as with requests
>for allowing fu
Reece Dunn wrote:
... ... ...
This should have been (with a default namespace):
...
...
...
Regards,
Reece
_
Stay in touch with absent friends - get MSN Messenger
http://www.msn.co.uk/messenger
_
Hamish Mackenzie wrote:
How about this for reading an input stream...
xml::dom::document doc( parse_stream( std::cin.rdbuf() ) );
I like this facility. You could also make it accept an istream like this:
class parse_stream
{
public:
parse_stream( istream & is ): sb( is.rdbuf()){...}
Hamish Mackenzie wrote:
On Fri, 2003-06-13 at 14:11, Stefan Seefeld wrote:
Hmm, I see your point. Well, that would be possible, but that way you
are unable to make nodes polymorphic. Neither with respect to the basic
node types (Element, Attribute, Text, CData, etc.) nor later when
implementing r
On Fri, 2003-06-13 at 14:11, Stefan Seefeld wrote:
> Hmm, I see your point. Well, that would be possible, but that way you
> are unable to make nodes polymorphic. Neither with respect to the basic
> node types (Element, Attribute, Text, CData, etc.) nor later when
> implementing real DOM support o
> I'm afraid I'm asking somebody else to do work here
though. I've got a resizing circular buffer (Metrowerks::cdeque has
shipped with CodeWarrior for years), but I'm not at liberty to share the
source.
I'm busy too, on my agenda is a 2-dimensional circular buffer
concept - which l
Loïc Joly said:
> William E. Kempf wrote:
>>I sympathize, but it's just not reasonable. Again, read the archives.
>
> Thank you for your fast answer !
>
> I did try to look in the archives before posting my mail, but I could no
> find a relevant mail in this huge archive. Could you remember roug
Ulrich Eckhardt said:
> On Thursday 12 June 2003 17:05, William E. Kempf wrote:
>> JOLY Loic said:
>> > 1/ Dynamic libraries
>> > Although I compiled boost with the option "-sBUILD=debug release
>> static/dynamic", the library is still generated as a
>> DLL. I do not exactly know what is meant by
"Alex Chovanec" <[EMAIL PROTECTED]> writes:
> Now you have a range of proxies to all of the objects in the first range
> that also appear in the second range. You could apply a transformation to
> the original copies of those objects in [begin1, end1) using the following
> function call.
I haven'
On Fri, 2003-06-13 at 12:14, Peter Dimov wrote:
> Hamish Mackenzie wrote:
> >
> > 3) Why dom::basic_document::clone? Why not have the copy constructor
> > and assignment operator should do a deep copy of the document? This
> > is consistent with other containers. If you want to stick with clone
>
Hamish Mackenzie wrote:
That way I'v got a pointer from the C struct to the C++ wrapper
(_private), as well as a pointer from the C++ wrapper to the C struct
(my_impl).
Would a thin proxy object not be a better way to go? More in keeping
with the "you don't pay for what you don't use" philosoph
> the attached patch changes the order in which compilers are checked in
> config/select_compiler.hpp. This is required to detect Comeau C++
> with gcc backend correctly.
>
> ok to apply?
Please go ahead,
Thanks,
John Maddock
___
Unsubscribe & other
Look for emails with the subject: "Thread Lib and DLL" arround the date:
3/26/2003
Viv
- Original Message -
From: "Loïc Joly" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Friday, June 13, 2003 12:55 AM
Subject: Re: [boost] Threads and msvc 7
> William E. Kempf
Hamish Mackenzie wrote:
>
> 3) Why dom::basic_document::clone? Why not have the copy constructor
> and assignment operator should do a deep copy of the document? This
> is consistent with other containers. If you want to stick with clone
> return
> an auto_ptr and and derive basic_document from b
Alex Chovanec wrote:
>
> I suppose for starters, you could create a generic binary function for
> operator< and other operators, maybe something like this:
>
> template
> struct ptr_less
> {
> bool operator()(const T * lhs, const T * rhs)
> {
> return (*lh
38 matches
Mail list logo
