Re: [boost] Threads and msvc 7
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 "static" in this case. > > specifies how you link against the C RTL, not what type of > library will be built. > > Currently (and for the forseeable future), Boost.Threads will only produce > dynamic link libraries. Read the mail archives for a detailed explanation > of why. There is on rather hackish way to use static linkage. We simply setup three .cpp-files that included the .cpp-files from out of the boost sourcetree. Works fine for 1.28 and 1.29 and only required one conditional for 1.30. If there is interest, I can post these files here (I'm not at work atm...). hth Ulrich Eckhardt ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any Interest in an Adapter for Sequences of Pointers?
Hi Thorsten,
Thank you for your feedback.
> You can avoid your handcoded loop by something like
>
> transform( ..., &address_of );
>
I suppose that's true. If you have a unary address_of() function, you can do
it cleanly enough with a transform.
> What would have been nice was some kind of template that could generate
> oprator<, operator= etc
> if there was a non-pointerversion of the class.
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 (*lhs < *rhs);
}
};
Going one step further, you could create a generic adapter for any binary
predicate:
template
struct ptr_predicate
{
bool operator()(const T * lhs, const T * rhs)
{
Predicate pred;
return pred(*lhs, *rhs);
}
};
Then you could instantiate it like this:
ptr_predicate > my_predicate;
That gets a little clunky though. What I had in mind is a mechanism where
you don't have to define a predicate for comparing pointers. Instead, you
would be able to use existing predicates for comparing objects.
My idea for implementing this was to pass a proxy that encapsulates a
pointer to an object of type T and defines some basic pointer operations,
like operator* and operator->. The key is that it also has an implicit
conversion to a const T &. That way, you could pass two of these proxies
directly to std::less.
When it comes to operator= though, they would just perform shallow copies.
This way, you can have value semantics for comparisons and reference
semantics for copy, assignment, swap, etc. There would also be an implicit
conversion constructor that takes a T & as a parameter. That way, you could
assign a T & to a proxy.
With these operators, you could avoid using a call to transform (not that
it's a terrible thing to use transform). You could just apply the algorithm
you want directly.
For instance, suppose you wanted to perform an std::set_insersection on two
ranges of objects, and then modify each object in the first range that also
appears in the second. You could do this:
. . .
// make sure my_permutation is big enough to hold the result
my_permutation.resize(std::min(end1 - begin1, end2 - begin2));
// calculate the intersection
std::set_intersection(
begin1, end1, begin2, end2,
std::back_inserter(my_permutation));
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.
std::for_each(
my_permutation.begin(),
my_permutation.end(),
some_functor());
I think this ability to go back and modify elements from the source range
via proxies in the destination range could be very useful.
Unfortunately (sigh), there is a problem here that I have not found a
satisfactory solution to. The preceding example with std::set_intersection
should (most likely) work. However, some other STL algorithms (e.g.
std::unique_copy) make local copies of objects from the source range and
then assign those copies to elements in the destination range. Since these
proxies provide shallow copy semantics, this places dangling pointers to
destroyed objects in my_permutation.
Looking at some different STL implementations, this use of local copies does
not appear to be too widespread, but it does occur. So function calls like
the preceding one to std::set_intersection are somewhat risky. As I said, I
have not found a satisfactory solution to this problem.
Still, this is only an issue if you pass iterators to objects as a source
range and iterators to proxies as a destination range. You can safely use
algorithms to assign proxies to proxies or proxies to objects, so the
preceding call would be ok if both of the source ranges were ranges of
proxies.
I'm still working on a solution to the other problem. Any suggestions would
be appreciated.
Cheers,
Alex
"Thorsten Ottosen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Alex,
>
> > There are many more possibilities beyond those described here. Does this
> > sound interesting to anyone
>
> I don't have time to comment very thoroughly, but I can say that it does
> sound
> interesting. In the project I'm working on now I needed to sort the
pointers
> from
> several containers which was not that hard.
>
> > // widgets_ and widget_ptrs_ get populated with some values
> > . . .
> > for (unsigned int i = 0; i < widgets_.size(); ++i)
> > {
> > widget_ptrs_.push_back(&widgets_[i]);
> > }
>
> You can avoid your handcoded loop by something like
>
> transform( ..., &address_of );
>
> of course you would have to resize the destination vector, but wouldn't
you
> do that
>
RE: [boost] [filesystem] "." directory-placeholder added
Title: RE: [boost] [filesystem] "." directory-placeholder added 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 full URI syntax in paths; without any mechanism in the >operational functions allowing those paths, what would be the point? The point is that there is a common need for parsing, combining, and otherwise manipulating URI and other paths prior to forwarding them to another system that processes that format. This may not be a mission of the filesystem library, but it is an important use case. Glen
Re: [boost] API Review request: XML APIs for C++
On Thu, 2003-06-12 at 22:12, Stefan Seefeld wrote:
> I'm wrapping libxml2. The structs provided by libxml2 all carry a
> '_private' member, precisely because it's a good way for extensions
> such as language wrapping.
> libxml2 itself calls callbacks whenever it allocates instances of these
> structs, and I allocate my C++ wrappers in these callbacks, and let the
> _private member point to it.
> 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" philosophy of C++.
I have attached the wrappers I have written. They do not cover much of
libxml2 (just what I needed at the time). Feel free to borrow as much
or as little from it as you like.
If you look in node_iterator.h you can see that it uses a proxy
containing just a pointer to the libxml2 node.
Looking up this node's parent node is thus simply
> static_cast(this->my_impl->parent->_private);
If there was a parent lookup in node_proxy it would be
class node_proxy
{
public:
node_proxy parent() { return node_proxy( node_->parent ); }
...
private:
xmlNodePtr node_;
};
> > Here are some suggestions...
> >
> > 1) parse_file could be
> >
> > class parse_file
> > {
> > public:
> > parse_file( const std::string & ) : {}
> > ...
> > };
>
> making 'parse_file' a class suggests it is carrying some data/state.
> What would that be ? I'm thinking of 'parse_file' as a stateless
> factory, i.e. a function returning a newly created document.
Sorry I should have included the ... bit
class parse_file
{
public:
parse_file( const std::string & f ) : file_name_ {}
private:
const std::string & file_name_;
template< ... >
friend class ::boost::xml::dom::document;
};
Put that together with the constructor...
template<...>
class basic_document
{
public:
basic_document( const parse_file & f )
{
// does what parse_file function does now
}
};
And you can write code that goes
xml::dom::document doc( xml::dom::parse_file( "a.xml" ) );
No auto_ptr needed. It's not in my wrappers as I only thought of it
while I was reading through yours.
> > 2) How about parse_string (based on xmlParseMemory)?
>
> hmm, while that would be possible, I think it's more C++'ish to
> provide document extraction from a std::streambuf, which could be
> a string_buf or any other buffer implementation. (Note that I wouldn't
> use std::iostreams as that would suggest that formatted extraction is
> possible, which would only work on ascii, not on unicode content.
parse_stream would indeed be even better. As I recall there are
functions in libxml2 that allow you to write to the parser as well.
How about this for reading an input stream...
xml::dom::document doc( parse_stream( std::cin.rdbuf() ) );
and if you want to write to to the parser (for instance if the data is
coming from a series of asynchronous read operations).
class document
{
public:
std::streambuf & parser();
};
xml::dom::document doc;
doc.parser().write( buffer, buffer_size );
> > 4) How about something like
> >
> > class basic_document
> > {
> > public:
> > ...
> >
> > typedef node_iterator iterator;
> > typedef const_node_iterator const_iterator;
> >
> > iterator begin()
> > { return iterator( ptr_->children ); }
> > const_iterator begin() const
> > { return const_iterator( ptr_->children ); }
> > iterator end() { return iterator(); }
> > const_iterator end() const { return const_iterator(); }
> >
> > iterator root()
> > { return iterator( xmlDocGetRootElement( ptr_ ) ); }
> > const_iterator root() const
> > { return const_iterator( xmlDocGetRootElement( ptr_ ) ); }
> > };
>
> I don't understand: are you suggesting an iterator that traverses
> the whole tree (as opposed the children of a single node) ?
No just the children. If figure node.begin() and node.end() be fore
iteration over the child nodes.
--
Hamish Mackenzie <[EMAIL PROTECTED]>
xml_stuff.tar.gz
Description: application/compressed-tar
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and msvc 7
William E. Kempf wrote: JOLY Loic said: Hello, I am currently trying to use the Boost.Threads library on windows (VC++ 7.0 and 7.1 compilers), and I wonder about some points : [...] What I know is I would appreciate to link fully statically with a .lib file and no .dll at run-time. 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 roughly at what time this discussion took place to help me narrow my search ? Regards, -- Loïc ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review Request: cyclic_buffer
On Thursday, June 12, 2003, at 12:43 PM, Nigel Stewart wrote: I can see the appeal here in using a circular buffer in this manner, while at the same time I'm cooling against the compromise of "insert auto-resizes, while push doesn't" which seems inconsistant. Given that we both seem to have a real-time orientation, we're probably not so far apart in our thinking. Perhaps we simply need to make a distinction between a circular_buffer and a circular_deque which are only different in terms of resizing semantics. Each provides different characteristics, and stand independently as boost containers. Code re-use by itself doesn't seem to be a good enough reason to mix the concepts and overload the namespace unnecessarily. I'm beginning to think you're correct. An informed process would be to create both containers, and adapt both types to the other, and measure the results. 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. And my schedule is tight enough that even higher priority things are slipping right now, so I can't donate cycles to a non-resizing variant to compare to. One idea that came to my mind was to have "forward insertion", "backward insertion" to resolve the question of semantics of arbitrary insertion into a circular_buffer. insert() pushes rightmost items forwards, overwriting leftmost items as necessary. rinsert() pushes leftmost items backwards, overwriting rightmost items as necessary. Likewise for the circular_deque which would reallocate as necessary to accomodate any kind of insertion - items would never be implicitly lost by a circular_deque. This sounds very interesting for the non-resizing version. I think for the resizing version, the insert should simply minimize the elements that it is going to move. Either way, all pointers and iterators must be considered invalidated (unlike the non-resizing variant with insert and rinsert). In my mind, when you insert into the middle of a resizing circular buffer, the behavior (mental model) is very deque-like, except of course for the ability to predict whether it will require a reallocation or not. -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] "." directory-placeholder added
At 01:31 PM 6/12/2003, Daryle Walker wrote:
>On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
>
>> An updated version of Boost.Filesystem has been added to CVS. The
>> primary change is adding "." as a directory-placeholder to the generic
>> path grammar.
>>
>> This solves the problem of distinguishing between an empty path and
>> one that acts as a placeholder.
>>
>> This change does change some existing behavior: path("foo/..") used to
>> get converted to an empty path. Now it gets converted to a path of
>> ".", and thus the change will break any existing code which depended
>> on the prior behavior.
>
>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 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 full URI syntax in paths; without any mechanism in the operational
functions allowing those paths, what would be the point?
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML APIs for C++
Hamish Mackenzie wrote:
Looks good. I have only looked at the dom stuff so far. Why are you
storing information in _private? What goes in there that could not be
extracted when the nodes are accessed? It seems like a lot of
unnecessary overhead.
I'm wrapping libxml2. The structs provided by libxml2 all carry a
'_private' member, precisely because it's a good way for extensions
such as language wrapping.
libxml2 itself calls callbacks whenever it allocates instances of these
structs, and I allocate my C++ wrappers in these callbacks, and let the
_private member point to it.
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).
Looking up this node's parent node is thus simply
static_cast(this->my_impl->parent->_private);
Here are some suggestions...
1) parse_file could be
class parse_file
{
public:
parse_file( const std::string & ) : {}
...
};
making 'parse_file' a class suggests it is carrying some data/state.
What would that be ? I'm thinking of 'parse_file' as a stateless
factory, i.e. a function returning a newly created document.
2) How about parse_string (based on xmlParseMemory)?
hmm, while that would be possible, I think it's more C++'ish to
provide document extraction from a std::streambuf, which could be
a string_buf or any other buffer implementation. (Note that I wouldn't
use std::iostreams as that would suggest that formatted extraction is
possible, which would only work on ascii, not on unicode content.
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 boost::noncopyable.
fair enough.
4) How about something like
class basic_document
{
public:
...
typedef node_iterator iterator;
typedef const_node_iterator const_iterator;
iterator begin()
{ return iterator( ptr_->children ); }
const_iterator begin() const
{ return const_iterator( ptr_->children ); }
iterator end() { return iterator(); }
const_iterator end() const { return const_iterator(); }
iterator root()
{ return iterator( xmlDocGetRootElement( ptr_ ) ); }
const_iterator root() const
{ return const_iterator( xmlDocGetRootElement( ptr_ ) ); }
};
I don't understand: are you suggesting an iterator that traverses
the whole tree (as opposed the children of a single node) ?
While that would be possible, I don't think it would actually
be useful. I'v written a Visitor which I use to look up specific
nodes. As the node 'type system' is known without C++ RTTI that
doesn't require double dispatching though...
5) basic_xpath and basic_xpath_result should be derived from
boost::noncopyable
ok
6) Leading _ chars are a no no (reserved for compiler implementors). I
know _private is defined in libxml2, but what you see below is not...
ok
Thanks for the feedback !
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML APIs for C++
Looks good. I have only looked at the dom stuff so far. Why are you
storing information in _private? What goes in there that could not be
extracted when the nodes are accessed? It seems like a lot of
unnecessary overhead.
Here are some suggestions...
1) parse_file could be
class parse_file
{
public:
parse_file( const std::string & ) : {}
...
};
template<...>
class basic_document
{
public:
basic_document( const parse_file & );
}
2) How about parse_string (based on xmlParseMemory)?
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 boost::noncopyable.
4) How about something like
class basic_document
{
public:
...
typedef node_iterator iterator;
typedef const_node_iterator const_iterator;
iterator begin()
{ return iterator( ptr_->children ); }
const_iterator begin() const
{ return const_iterator( ptr_->children ); }
iterator end() { return iterator(); }
const_iterator end() const { return const_iterator(); }
iterator root()
{ return iterator( xmlDocGetRootElement( ptr_ ) ); }
const_iterator root() const
{ return const_iterator( xmlDocGetRootElement( ptr_ ) ); }
};
5) basic_xpath and basic_xpath_result should be derived from
boost::noncopyable
6) Leading _ chars are a no no (reserved for compiler implementors). I
know _private is defined in libxml2, but what you see below is not...
$ grep ' _' *
basic_attribute.h:#ifndef _dom_basic_attribute_h
basic_attribute.h:#define _dom_basic_attribute_h
basic_comment.h:#ifndef _dom_basic_comment_h
basic_comment.h:#define _dom_basic_comment_h
basic_document.h:#ifndef _dom_basic_document_h
basic_document.h:#define _dom_basic_document_h
basic_dtd.h:#ifndef _dom_basic_dtd_h
basic_dtd.h:#define _dom_basic_dtd_h
basic_element.h:#ifndef _dom_basic_element_h
basic_element.h:#define _dom_basic_element_h
basic_node.h:#ifndef _dom_basic_node_h
basic_node.h:#define _dom_basic_node_h
basic_node.h: basic_node_iterator(impl *current = 0) :
_current(current) {}
basic_node.h: bool operator == (self i) { return _current ==
i._current;}
basic_node.h: void increment() { _current = _current->next;}
basic_node.h: void decrement() { _current = _current->prev;}
basic_node.h: basic_node_const_iterator(const impl *current = 0) :
_current(current) {}
basic_node.h: bool operator == (self i) { return _current ==
i._current;}
basic_node.h: void increment() { _current = _current->next;}
basic_node.h: void decrement() { _current = _current->prev;}
basic_pi.h:#ifndef _dom_basic_pi_h
basic_pi.h:#define _dom_basic_pi_h
basic_text.h:#ifndef _dom_basic_text_h
basic_text.h:#define _dom_basic_text_h
basic_traversal.h:#ifndef _dom_basic_traversal_h
basic_traversal.h:#define _dom_basic_traversal_h
Hamish
On Thu, 2003-06-12 at 03:45, Stefan Seefeld wrote:
> hi there,
>
> following some discussion we had some weeks ago,
> I'd like to invite everybody to review xml++.tgz at
>
> http://groups.yahoo.com/group/boost/files/xml/
>
> It's a DOM-like and a SAX-like API currently implemented
> on top of libxml2 (http://www.xmlsoft.org).
>
> What it provides:
>
> * parsing of xml files and creation of a document tree
> * manipulation of document tree, i.e. insertion and
>deletion of nodes
> * node iteration, search (xpath based)
> * document output to a (xml) file
>
> * event driven xml file parsing (sax)
>
> To be added:
>
> * validation (dtd, schema, etc.)
> * ?
>
> Is there any interest in this library evolving
> into a boost::xml library ? If so, what needs to change,
> what needs to be added / removed ?
>
> Regards,
> Stefan
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Hamish Mackenzie <[EMAIL PROTECTED]>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] patch to select_compiler.hpp for Comeau C++
Hi, 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? Regards, m Index: select_compiler_config.hpp === RCS file: /cvsroot/boost/boost/boost/config/select_compiler_config.hpp,v retrieving revision 1.5 diff -u -r1.5 select_compiler_config.hpp --- select_compiler_config.hpp 23 May 2003 07:03:20 - 1.5 +++ select_compiler_config.hpp 12 Jun 2003 20:31:36 - @@ -10,13 +10,14 @@ // locate which compiler we are using and define // BOOST_COMPILER_CONFIG as needed: -#if defined __GNUC__ +# if defined __COMO__ +// Comeau C++ +# define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" + +# elif defined __GNUC__ // GNU C++: # define BOOST_COMPILER_CONFIG "boost/config/compiler/gcc.hpp" -# elif defined __COMO__ -// Comeau C++ -# define BOOST_COMPILER_CONFIG "boost/config/compiler/comeau.hpp" #elif defined __KCC // Kai C++ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in library generating streambufs fromobjects
Larry Evans wrote: [snip] Any comments? Maybe this method could be used Yeah. What happens when ostream destructor is called. Since this probably calls the streambuf destructor, and if the streambuf is actually a fwd_streambuf, and the ~fwd_streambuf resets the ostream.rdbuf, this just may be a problem :(. IOW, OOPS. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in library generating streambufs fromobjects
Larry Evans wrote: [snip] The prototype of the "using overflow+sputc" method is in files/col_io/test_fwd_streambuf.zip. A more complete marg_ostream example is in files/col_io/test_marg_ostreambuf.zip. It shows how an ostream indentation can be changed without resorting to a wrapper class like marg_ostream in col_io/col_io.zip. It also shows how to change the indentation with use of dynamic_cast and call to marg_ostreambuf member function. It also shows how the original status of the ostream can be restored by simply deleting the result of ostream::rdbuf. Any comments? Maybe this method could be used with Maxim's adaptors? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] "." directory-placeholder added
On Thursday 12 June 2003 01:31 pm, Daryle Walker wrote:
> On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
> > An updated version of Boost.Filesystem has been added to CVS. The
> > primary change is adding "." as a directory-placeholder to the generic
> > path grammar.
> >
> > This solves the problem of distinguishing between an empty path and
> > one that acts as a placeholder.
> >
> > This change does change some existing behavior: path("foo/..") used to
> > get converted to an empty path. Now it gets converted to a path of
> > ".", and thus the change will break any existing code which depended
> > on the prior behavior.
>
> Is it possible to override this and use "." or ".." as regular object
> names?
>
>
Do I understand correctly that you are proposing that "." or ".." are to be
used as the names of e.g., files? It's hard to see a need for it.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Thread errors and vc7
"William E. Kempf" <[EMAIL PROTECTED]> wrote: > ...The warnings are known and will > be fixed soon. Ignore them for now. I have built the dll version of the threads library several times, with the mentioned warnings, which I ignore. However, once in a while I get one or two unamed errors (i..e., there is no C or LNK code associated with them.) The errors always reference . I delete all the compiler generated files, rebuild, hold my breath, and _usually_ there are no more errors. The library seems to work fine, but these errors make me very nervous. Jonathan Turkanis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Interest in library generating streambufs
Maxim Egorushkin wrote: > I posted here a while ago streambuf adapters. There was no any answer. May > be you might find it intresting. > > The main idea is simple: to present any linear sequence as > std::basic_streambuf<>. Yes, this is very elegant. No codecvt's in sight -- just pure adaptors. Also nice treatment of optional template parameters. It puts my design (and certain my implementation) to shame. I should have thought more about the general idea of composition before responding to posts. Repositioning may not be releavnt to the type of applications discussed (encryption, formating, etc.) but it is important sometimes and deserves a good general treatment. Also, the ability to add a putback buffer is useful. Yours (humbly), Jonathan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [filesystem] "." directory-placeholder added
On Thursday, June 12, 2003, at 11:23 AM, Beman Dawes wrote:
An updated version of Boost.Filesystem has been added to CVS. The
primary change is adding "." as a directory-placeholder to the generic
path grammar.
This solves the problem of distinguishing between an empty path and
one that acts as a placeholder.
This change does change some existing behavior: path("foo/..") used to
get converted to an empty path. Now it gets converted to a path of
".", and thus the change will break any existing code which depended
on the prior behavior.
Is it possible to override this and use "." or ".." as regular object
names?
Daryle
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review Request: cyclic_buffer
deque is more expensive than a resizing circular buffer in both performance and code size. One also can not control *when* deque will allocate as one can with a resizing circular buffer. In a nutshell, a resizing circular buffer is often a better deque than std::deque is. ;-( A resizing circular buffer is absolutely awesome when plugged into std::queue. If your queue on average doesn't constantly grow, a resizing circular buffer is efficient, predictable and safe. A std::deque in std::queue will likely continually rellocate buffers as it drops one off one end and adds one to the other (and at annoyingly unpredictable times if you're doing real-time). Howard, I can see the appeal here in using a circular buffer in this manner, while at the same time I'm cooling against the compromise of "insert auto-resizes, while push doesn't" which seems inconsistant. Given that we both seem to have a real-time orientation, we're probably not so far apart in our thinking. Perhaps we simply need to make a distinction between a circular_buffer and a circular_deque which are only different in terms of resizing semantics. Each provides different characteristics, and stand independently as boost containers. Code re-use by itself doesn't seem to be a good enough reason to mix the concepts and overload the namespace unnecessarily. One idea that came to my mind was to have "forward insertion", "backward insertion" to resolve the question of semantics of arbitrary insertion into a circular_buffer. insert() pushes rightmost items forwards, overwriting leftmost items as necessary. rinsert() pushes leftmost items backwards, overwriting rightmost items as necessary. Likewise for the circular_deque which would reallocate as necessary to accomodate any kind of insertion - items would never be implicitly lost by a circular_deque. Nigel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads and msvc 7
> > No, there is no MFC dependency. Changing your project settings to use the > MFC dll cleared the warnings because this change also effects how you link > against the C RTL. When you tried to compile the project with no MFC you > got the error you did because you failed to compile against a > multi-threaded C RTL. All dependencies in Boost.Threads are with the C > RTL and not MFC. You are right. When I changed the project settings to "no MFC support", it silently changed the code generation option from multithreaded to single-threaded - I had wrongly assumed that the state multi/single threaded would be preserved. Cheers, Adrian ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads and msvc 7
Adrian Michel said: > I am using MSVC 6, but I run into the same problem. Changing the project > settings to use the MFC dll cleared the warnings. > > Moreover, I tried to run my project with no MFC support and I got this > message: > d:\documents and > settings\administrator\desktop\dev\boost_1_30_0\boost\thread\thread.hpp(17) > : fatal error C1189: #error :Thread support is unavailable! > > I did look deeper into the problem, but there seems to be some hidden > MFC dependency in the thread libraries. No, there is no MFC dependency. Changing your project settings to use the MFC dll cleared the warnings because this change also effects how you link against the C RTL. When you tried to compile the project with no MFC you got the error you did because you failed to compile against a multi-threaded C RTL. All dependencies in Boost.Threads are with the C RTL and not MFC. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads and msvc 7
William, > > I did look deeper into the problem, but there seems to be some hidden MFC > dependency in the thread libraries. This should read "I did _not_ look deeper...". Other than this very minor issue, the thread library works beautifully and I am not planning on using any native thread APIs any more. Thanks for making it publicly available! Adrian ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads and msvc 7
I am using MSVC 6, but I run into the same problem. Changing the project settings to use the MFC dll cleared the warnings. Moreover, I tried to run my project with no MFC support and I got this message: d:\documents and settings\administrator\desktop\dev\boost_1_30_0\boost\thread\thread.hpp(17) : fatal error C1189: #error :Thread support is unavailable! I did look deeper into the problem, but there seems to be some hidden MFC dependency in the thread libraries. Adrian > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of William E. Kempf > Sent: Thursday, June 12, 2003 8:30 AM > To: [EMAIL PROTECTED] > Subject: RE: [boost] Threads and msvc 7 > > > > Adrian Michel said: > >> 2/ The use of DLL-exported classes that derive from or uses as member > >> variables non-DLL-exported classes is generating some warnings by msvc > >> that fall into two categories (4275 and 4251). Would it be possible to > >> insert #pragma to remove these spurious warnings ? > >> > > These warnings are generated because your project is set to link with > > the static version of the MFC library, while the boost libraries link > > with the MFC dll. Change the settings in your project and they will > > disappear. > > No MFC library is used by Boost.Threads. The warnings are known and will > be fixed soon. Ignore them for now. > > -- > William E. Kempf > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML APIs for C++
Peter Dimov wrote:
Looks reasonable, but we don't want the architecture of the backend to
affect the interface.
right. So what is would be reasonable semantics to expect from a dom API
? May be I'v just got used to libxml2's way of life, but I think it is
a good choice. Nodes are owned by their parents, so you can do
dom::element *child = parent->add_child("info");
And calling
dom::element::iterator i = parent->find(child);
parent->erase_child(i);
will invalidate 'child'. I don't know of any way to make that more safe
while still being efficient.
There is also the problem that the user can be left
with an invalid pointer after the document has been deleted.
Yes, but is that a problem ? Of course it has to be written in bold
strokes: "Don't delete a document while operating on its content !",
but I think the main idea to get across is that nodes *can only* exist
in the context of a document. That's not only because of memory
ownership issues, but also for a variety of other contextual data
associated with a node, such as namespaces.
I had a long discussion with the libxml2 author about ownership
semantics and he convinced me that the current way is the best tradeoff
between simplicity/ease of use and efficiency.
Since the DOM is a tree and has no cycles, it should be possible to get
fairly close to the Java interface using strict ownership or shared_ptr
underneath. In the libxml2 case every Node would need to keep the whole
Document alive but this may not be necessary given a different backend.
I don't understand that. The document owns its nodes, so letting nodes
reference the document would create loops, no ?
Of course if this isn't practical a quick fix would be to return a
shared_ptr from parse_file.
yeah, that's unrelated. But why not std::auto_ptr then ?
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads and msvc 7
Adrian Michel said: >> 2/ The use of DLL-exported classes that derive from or uses as member >> variables non-DLL-exported classes is generating some warnings by msvc >> that fall into two categories (4275 and 4251). Would it be possible to >> insert #pragma to remove these spurious warnings ? >> > These warnings are generated because your project is set to link with > the static version of the MFC library, while the boost libraries link > with the MFC dll. Change the settings in your project and they will > disappear. No MFC library is used by Boost.Threads. The warnings are known and will be fixed soon. Ignore them for now. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [filesystem] "." directory-placeholder added
An updated version of Boost.Filesystem has been added to CVS. The primary
change is adding "." as a directory-placeholder to the generic path
grammar.
This solves the problem of distinguishing between an empty path and one
that acts as a placeholder.
This change does change some existing behavior: path("foo/..") used to get
converted to an empty path. Now it gets converted to a path of ".", and
thus the change will break any existing code which depended on the prior
behavior.
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Threads and msvc 7
Hello, I am currently trying to use the Boost.Threads library on windows (VC++ 7.0 and 7.1 compilers), and I wonder about some points : 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 "static" in this case. What I know is I would appreciate to link fully statically with a .lib file and no .dll at run-time. 2/ The use of DLL-exported classes that derive from or uses as member variables non-DLL-exported classes is generating some warnings by msvc that fall into two categories (4275 and 4251). Would it be possible to insert #pragma to remove these spurious warnings ? -- Loïc ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and msvc 7
JOLY Loic said: > Hello, > > I am currently trying to use the Boost.Threads library on windows (VC++ > 7.0 and 7.1 compilers), and I wonder about some points : > > 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 "static" in this case. specifies how you link against the C RTL, not what type of library will be built. Currently (and for the forseeable future), Boost.Threads will only produce dynamic link libraries. Read the mail archives for a detailed explanation of why. > What I know is I would appreciate to link fully statically with a .lib > file and no .dll at run-time. I sympathize, but it's just not reasonable. Again, read the archives. > 2/ The use of DLL-exported classes that derive from or uses as member > variables non-DLL-exported classes is generating some warnings by msvc > that fall into two categories (4275 and 4251). Would it be possible to > insert #pragma to remove these spurious warnings ? I'm addressing this issue. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads and msvc 7
> 2/ The use of DLL-exported classes that derive from or uses as member > variables non-DLL-exported classes is generating some warnings by msvc > that fall into two categories (4275 and 4251). Would it be possible to > insert #pragma to remove these spurious warnings ? > These warnings are generated because your project is set to link with the static version of the MFC library, while the boost libraries link with the MFC dll. Change the settings in your project and they will disappear. Cheers, Adrian ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML APIs for C++
Stefan Seefeld wrote: > Peter Dimov wrote: >> >> I think that there is considerable interest in a boost::xml library. >> But... >> >> Document *document = Document::parse_file(argv[1]); >> >> ... I don't believe that a raw pointer based interface is acceptable. >> >> xml::dom::document document = xml::dom::parse_file(argv[1]); >> >> looks much better. > > Good catch. However, it looks worse than it actually is :-) : > > The memory management for nodes is entirely handled by the backend > (libxml2), i.e. nodes are always created and deleted by their parents. > Constructors and destructors are protected. > > The 'Document' class is the only one that is owned directly by the > user, and thus has to be deleted. Looks reasonable, but we don't want the architecture of the backend to affect the interface. There is also the problem that the user can be left with an invalid pointer after the document has been deleted. Since the DOM is a tree and has no cycles, it should be possible to get fairly close to the Java interface using strict ownership or shared_ptr underneath. In the libxml2 case every Node would need to keep the whole Document alive but this may not be necessary given a different backend. Of course if this isn't practical a quick fix would be to return a shared_ptr from parse_file. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML APIs for C++
Peter Dimov wrote: Stefan Seefeld wrote: Is there any interest in this library evolving into a boost::xml library ? If so, what needs to change, what needs to be added / removed ? I think that there is considerable interest in a boost::xml library. But... Document *document = Document::parse_file(argv[1]); ... I don't believe that a raw pointer based interface is acceptable. xml::dom::document document = xml::dom::parse_file(argv[1]); looks much better. Good catch. However, it looks worse than it actually is :-) : The memory management for nodes is entirely handled by the backend (libxml2), i.e. nodes are always created and deleted by their parents. Constructors and destructors are protected. The 'Document' class is the only one that is owned directly by the user, and thus has to be deleted. BTW why is basic_document<>::write_file virtual but basic_document<>::clone isn't? hmm, good question. I don't see any need for it to be virtual, I wouldn't expect anybody to derive from Document. Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] API Review request: XML APIs for C++
Stefan Seefeld wrote: > > Is there any interest in this library evolving > into a boost::xml library ? If so, what needs to change, > what needs to be added / removed ? I think that there is considerable interest in a boost::xml library. But... Document *document = Document::parse_file(argv[1]); ... I don't believe that a raw pointer based interface is acceptable. xml::dom::document document = xml::dom::parse_file(argv[1]); looks much better. BTW why is basic_document<>::write_file virtual but basic_document<>::clone isn't? The SAX part looks OK to me. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in library generating streambufs fromobjects
Larry Evans wrote: [snip] with buffered input. After thinking some more, I thought about just using overflow and sputc to "pipe" the output to the next streambuf. This greatly simplified the code. Would something similar work with [snip] The prototype of the "using overflow+sputc" method is in files/col_io/test_fwd_streambuf.zip. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Interest in library generating streambufs fromobjects
Maxim Egorushkin wrote: [snip] I posted here a while ago streambuf adapters. There was no any answer. May be you might find it intresting. Sorry I overlooked it. The main idea is simple: to present any linear sequence as std::basic_streambuf<>. It sounds like what people, in particular Robert Ramey , wants. Here are the file. I had a brief look and it looks promising. However, I'm wondering if some of the complexity can be avoided. I had a hard time figuring out just how to get marg_ostreambuf in files/col_io/col_io.zip to work with buffered input. After thinking some more, I thought about just using overflow and sputc to "pipe" the output to the next streambuf. This greatly simplified the code. Would something similar work with your code. In particular, can you create an equivalent to marg_ostream from files/col_io/col_io.zip by using your, I guess, stream buffer redirectors? I'd like to see that. Maybe Reece Dunn would also since he's "interested in indentation facilities." ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML APIs for C++
Reece Dunn wrote: This means having a conversion manager in the traits class, e.g. agreed. It's already there, have a look ! Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML APIs for C++
Gennadiy Rozental wrote: Here is my vision on the problem, couple ideas on XML parser design: 1. No xmlChar type -> template parameter hmm, what code did you look at ? I *do* use templates for this. I use 'xmlChar' internally as that's the type used by libxml2. But that part is private, the public interface uses a 'string' template parameter in conjunction with a 'convert' trait that delivers the in/out conversion between xmlChar and 'string'. 2. No hardcoded virtual functions. In some refinements it still may come to use virtual functions here and there. One way to achieve this is to supply implementation as template parameter: I don't understand what's so 'outdated' about virtual functions. Why must I avoid them and use templates everywhere ? But I see your point, I could bind individual callback handlers with boost::function<>... 3. Most probably above may not be good enough. For better reusability let then use multiple template parameters for different types of handlers: Hmm, that looks pretty clumsy, considering the number of different handlers, and thus the numbers of template parameters. Why not just bind each handler callback individual to the parser, as parser already is a stateful object. 4. There maybe several "flavors" of document handlers. One simple: as usual concrete handler needs to expose methods like on_start_element and accept the name plus attributes. As an alternative we may consider document handlers supporting "named callbacks" (in a form of boost::function<...>) registration. IOW such handler would call a callback when element with desired name encountered. There are other alternatives. interesting. However, I'd suggest to add such convenience on top of a basic layer that is 'functionally complete'. I am sure that there also could be Spirit-based or Spirit-like solution. Check with the Spirit guys. Well, sure, people can always rewrite xml parsers. But as I suggested earlier, that is a *big* job, and there is much more than parsing, at least if you look not only at sax but dom etc. Regards, Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: API Review request: XML APIs for C++
Gennadiy Rozental wrote:
1. No xmlChar type -> template parameter
namespace xml {
template
class parser {...};
}
I agree with this, but think that the basic problem is with the underlying
implementation. The xml++ implementation makes use of libxml2, who's
underlying representation is xmlChar. I am not sure what this evaluates to,
but I'll assuming it evaluates to a char. If the library were to be ported
to another implementation, this may differ (the Microsoft parser uses
wchar_t).
This means having a conversion manager in the traits class, e.g.
Traits::representation_type * Traits::convert( Traits::value_type );
The question then is how do you manage possible allocation/deallocation of
memory, especially when the parameter may be passed through if the two types
are the same:
char * traits::convert( char * str ){ return( str ); }
A mechanism needs to be sorted out in order for this to be successful.
2. No hardcoded virtual functions. In some refinements it still may come to
use virtual functions here and there. One way to achieve this is to supply
implementation as template parameter:
I was aiming at a similar idea with my document loader, allowing the XML
document to be loaded in to the internal representation using a loader
class. There could then be implementations using libxml2, MSXML3/4, Spirit,
or another parser.
Regards,
Reece
_
Tired of 56k? Get a FREE BT Broadband connection
http://www.msn.co.uk/specials/btbroadband
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
> This discussion was a long time ago, but I didn't get the end of it. > As building the thread library I get a lot of warnings I would like > to remove them somehow (I'm using the 1.30 release version). > > So, what would you suggest? Using pragma's is safe enough? > If yes, where is the best place to add this ? Just for the record, the list of warnings from vc7.1 is rather long (see below), it would be nice if we could fix these, John. -- Build started: Project: boost_thread, Configuration: Debug Win32 -- Compiling... xtime.cpp tss.cpp c:\data\boost\develop\boost\boost\thread\tss.hpp(33) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::detail::tss' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\tss.hpp(32) : see declaration of 'boost::detail::tss' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(35) : warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' threadmon.cpp thread.cpp c:\data\boost\develop\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(35) : warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' c:\data\boost\develop\boost\boost\thread\mutex.hpp(37) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::mutex' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\mutex.hpp(36) : see declaration of 'boost::mutex' c:\data\boost\develop\boost\boost\thread\mutex.hpp(75) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::try_mutex' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\mutex.hpp(74) : see declaration of 'boost::try_mutex' c:\data\boost\develop\boost\boost\thread\mutex.hpp(115) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::timed_mutex' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\mutex.hpp(114) : see declaration of 'boost::timed_mutex' c:\data\boost\develop\boost\boost\thread\thread.hpp(39) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\thread.hpp(38) : see declaration of 'boost::thread' c:\data\boost\develop\boost\boost\thread\thread.hpp(68) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread_group' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\thread.hpp(67) : see declaration of 'boost::thread_group' c:\data\boost\develop\boost\boost\thread\thread.hpp(79) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ] c:\data\boost\develop\boost\boost\thread\condition.hpp(38) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::detail::condition_impl' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\b
RE: [boost] mpl size::type varies across compilers
Hugo Duncan wrote: > Aleksey and all, Hi Hugo, > > mpl::size returns integral_c on gcc, vc7.1 but > integral_c on bcc564. > > Is this intentional? Nope, it's a bug. Fixed in the main trunk. Thanks for the report, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Interest in library generating streambufs from objects
"Jonathan D. Turkanis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thanks for your interest. I have posted the library at
> http://groups.yahoo.com/group/boost/files/streambuf_lib/.
>
> The implementation needs to be streamlined, but it works, and the main
ideas
> are clear enough.
Hi,
I posted here a while ago streambuf adapters. There was no any answer. May
be you might find it intresting.
The main idea is simple: to present any linear sequence as
std::basic_streambuf<>.
Here are the file.
begin 666 sequence_buffer.hpp
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O#0HO+R!S97%U96YC95]B=69F97(N: T*#0HC<')A9VUA(&]N8V4-
M"@T*(VEN8VQU9&4@/&%L9V]R:71H;3X-"B-I;F-L=61E(#QI=&5R871O6%B;&4N:'!P
M/@T*(VEN8VQU9&4@/&)O;W-T+W1Y<&5?=')A:71S+FAP<#X-"B-I;F-L=61E
M(#QB;V]S="]M<&PO=F]I9"YH<' ^#0HC:6YC;'5D92 \8F]O6YO<'-I
M&%M<&QE2!P87)A;65T
M97)S#0H)"6-L87-S('-E<75E;F-E7VUO9&5L#0H)+R\@;W!T:6]N86P@<&%R
M86UE=&5R2!P
M87)A;65T97)S#0H)"6-L87-S('-E<75E;F-E7VUO9&5L#0H)+R\@;W!T:6]N
M86P@<&%R86UE=&5RWT[#0IS=')[EMAIL PROTECTED]>F5?=&%G('M].PT*#0IT96UP;&%T
M93QC;&%SPT*"71Y<&[EMAIL PROTECTED]&%G(&YA;64[#0H)='EP961E9B!4('1Y<&4[#0I]
M.PT*#0IS=')[EMAIL PROTECTED]&5F875L=%]P87)A;65T97)?=&%G('M].PT*#0IS=')U
[EMAIL PROTECTED]&5F875L=%]P87)A;65T97(-"@DZ"61E9FEN95]P87)A;65T97(\9&5F
M875L=%]P87)A;65T97)?=&%G+"!M<&PZ.G9O:61?/B![?3L-"@T*+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M#0H-"G1E;7!L871E/&-L87-S(%0^#0IC;&%S7!E
M9&5F(&EN<'5T7W-E<75E;F-E7V-O;F-E<'0@:6YP=70[#0H-"@ES:7IE7W0@
MF5?="!S:7IE*2 O+R!B>71E(&)U9F9E
MF4I.PT*"7T-"GT[#0H-"G1E;7!L
M871E/&-L87-S(&UO9&5L/@T*8VQA7!E9&5F(&]U='!U=%]S97%U96YC95]C;VYC
M97!T(&]U='!U=#L-"@T*"79O:[EMAIL PROTECTED])I=&4H8V]N<[EMAIL PROTECTED]"[EMAIL
PROTECTED]
M+"!S:7IE7W0@<[EMAIL PROTECTED]@8GET92!B=69F97);PT*<')I=F%T93H-"@ET>7!E9&5F('1Y<&5N86UE('-T9#HZ:71EF4I#0H)>PT*"0EI9B HF5O9BAC:&%R7W1Y<&4I*0T*"0D)=&AR;W<@F4@/2!S=&0Z.FUI
M;CQS:7IE7W0^*'-I>[EMAIL PROTECTED]:7IE;V8H8VAA[EMAIL PROTECTED] M(&)E
M9VEN7RD[#0H)"7-T9#HZ8V]P>2AB96=I;E\L(&)E9VEN7R K('-I>F4L('-T
M871I8U]C87-T/&-H87)?='EP92H^*&)U9F9E[EMAIL PROTECTED]:7IE;V8H8VAA7!E*3L-"@E]
M#0H-"G!R:79A=&4Z#0H):71EF5O9BAC:&%R7W1Y<&4I
M(#X@F5O9BAC:&%R7W1Y<&4I.PT*"0ES=&0Z.F-O<'DH7!E*CXH8G5F9F5R*2P-"@D)"7-T871I8U]C87-T/&-O
M;G-T(&-H87)?='EP92H^*&)U9F9E<[EMAIL PROTECTED]:7IE+"!B96=I;E\I.PT*"0EB
M96=I;[EMAIL PROTECTED]@7!E(&-H87)?='EP93L-"@T*<'5B;&[EMAIL PROTECTED]
M"7!UF4I#0H)>PT*"0EI9B HF5O9BAC:&%R7W1Y
M<&4I*0T*"0D)=&AR;W<@7!E*CXH8G5F9F5R*2P-"@D)"7-T871I8U]C87-T/&-O;G-T(&-H
M87)?='EP92H^*&)U9F9E<[EMAIL PROTECTED]:7IE("\@WT[#0H-"G1E;7!L871E/&-L87-S
M(%0^#0IS=')[EMAIL PROTECTED]WT[#0H-"G1E;7!L871E
M/'-I>F5?="!S:7IE/@T*PT*#0IT96UP;&%T93QC;&%SPT*<'5B;&[EMAIL PROTECTED]"71Y<&[EMAIL PROTECTED]'EP96YA;64@7!E.PT*"71Y<&[EMAIL PROTECTED]'EP96YA;64@7!E9&5F('-T9#HZ8F%S
M:6-?R!S7RYR9&)U9BAB7RD[('T-"@T*"79O:60@
MPEB7R ]('-?+G)D8G5F*'[EMAIL PROTECTED]
M#0H)=F]I9"!F;'5S:"@I('[EMAIL PROTECTED]7!E/B8I('M]#0H-"@ES
M=')E86TF('-?.PT*"6)U9F9E<[EMAIL PROTECTED]("\O(&YA;65S<&%C
M92!D971A:6P-"@T*+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O#0HO+R!I7!E9&5F
M('-T9#HZ8F%S:6-?:7-TPT*"71Y<&5D968@7!E9&5F(&1E=&%I;#HZ7!E9&5F('1Y<&5N86UE(&)APT*"71Y<&5D
M968@7!E9&5F
M(&1E=&%I;#HZPT*
M"0ER961I7!E9&5F('-T9#HZ8F%S:6-?;W-T7!E;F%M92!D971A:6PZ.F]P=&EO;F%L7W!A7!E#0H)"3X-"@DL"7!R:79A=&[EMAIL PROTECTED]&5T86EL.CIO<'1I;VYA;%]P87)A
M;65T97)S/&)U9F9E7!E9&5F('1Y<&5N86UE('!A
M7!E.PT*"71Y<&[EMAIL PROTECTED]'EP
M96YA;64@<&%R86UE=&5RPT*"0ER96QE87-E7V)U9F9E<[EMAIL PROTECTED]"7T-"@T*
M<')O=&5C=&[EMAIL PROTECTED]"7-E<75E;F-E7V-O;F-E<'0F(&[EMAIL PROTECTED]
M('L@PT*"0D)8VAA7!E*B!B
M=69F97(@/2!A;&QO8V%T95]B=69F97(H*3L-"@D)"7-E=&F4I.PT*
M"0E]#0H)?0T*#0H)=F]I9"!PPT*"0ER971U<[EMAIL PROTECTED]&AIPT*"0ET:&ES+3YA;&QO8V%T;W(Z.F1E86QL;V-A=&4H96)A
[EMAIL PROTECTED]>F4I.PT*"0ES971G*# L(# L(# I.PT*#0H)"71H
M:7,M/F%L;&]C871O7!E;F%M92!S97%U96YC
M95]M;V1E;#HZ:6YP=70L(% Q+"!0,[EMAIL PROTECTED],L(% T/@T*>PT*<')I=F%T93H-
M"@ET>7!E9&5F(&1E=&%I;#HZ8G5F9F5R7V)A7!E"0EC:&%R7W1Y<&4[#0H)
M='EP961E9B!T>7!E;F%M92!B87-E.CITF5?= D)"0D)"6)U9F9EF4[#0H-"@ET>7!E9&5F('1Y<&5N86UE
M('-E<75E;F-E7VUO9&5L.CII;G!U="!S97%U96YC95]C;VYC97!T.PT*"0T*
M#0IP=6)L:6,Z#0H):6YP=71?8G5F9F5R*'-E<75E;F-E7V-O;F-E<'0F('-E
M<75E;F-E*0T*"0DZ"6)AWT-"@T*<')I=F%T93H-
M"@EI;G1?='EP92!U;F1EF5?="!R96%D.PT*"0EI9B H*')E860@/2!G971?
M7!E.CIT;U]I;G1?='[EMAIL PROTECTED])A8VLH*2D[#0H)"7T-"@D)96QS90T*
M"0E[#0H)"0ER971U<[EMAIL PROTECTED]')A:71S7W1Y<&[EMAIL PROTECTED]"0E]#0H)?0T*
M?3L-"@T*+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O#0H-"G1E;7!L871E/ T*"0EC;&%S7!E9&5F
M('1Y<&5N86UE(&)A7!E"0ET7!E9&5F('1Y<&5N86UE('1R86ET7!E.CII;G1?='EP90EI;G1?='EP
M93L-"@ES=&%T:6,@8V]NF4@/2!B
M87-E.CIB=69F97)?F5O9BAC
M:&%R7W1Y<&4I*3L-"@D)"7-E=' H<&)A<
RE: [boost] Bug: mpl::is_sequence (on MSVC7, at least)
Hi Eric, First of all, thanks for the report! Eric Friedman wrote: > I've found that mpl::is_sequence fails to operate correctly on > certain types under MSVC7. To be precise, on class types that have a member named 'begin' that is not a typename. > I haven't tested extensively, but there certainly seems to be some > problem with class templates from namespace std. (The problem likely > extends to other types in other namespaces, and perhaps other > compilers, but I have not investigated the issue thoroughly enough.) Nope, it doesn't have anything to do with namespaces, see the above. The affected compilers are MSVC 6.5 and 7.0. > > In particular, this is posing a problem for me in incorporating variant > into the next Boost release. Is this a known problem? Nope, it wasn't. > Any insight welcome. Fixed in the CVS. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any Interest in an Adapter for Sequences of Pointers?
Hi Alex,
> There are many more possibilities beyond those described here. Does this
> sound interesting to anyone
I don't have time to comment very thoroughly, but I can say that it does
sound
interesting. In the project I'm working on now I needed to sort the pointers
from
several containers which was not that hard.
> // widgets_ and widget_ptrs_ get populated with some values
> . . .
> for (unsigned int i = 0; i < widgets_.size(); ++i)
> {
> widget_ptrs_.push_back(&widgets_[i]);
> }
You can avoid your handcoded loop by something like
transform( ..., &address_of );
of course you would have to resize the destination vector, but wouldn't you
do that
anyway to save some allocations?
What would have been nice was some kind of template that could generate
oprator<, operator= etc
if there was a non-pointerversion of the class.
regards
Thorsten
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
