[boost] Re: boost::pool feature requests
Thanks Steve, for considering my issues. 4) what's the use of ordered_alloc/ordered_free? I made a few tests and they are indeed a bit slower than regular alloc/free, without any apparent advantage. Am I missing something? Keeping the free list ordered allows algorithms that traverse the free list along with the memory owned by pool to work correctly/more efficiently: 1) array allocations will be more efficient (pool_allocator keeps its free list ordered, whereas fast_pool_allocator does not) 2) release_memory() will work correctly 3) object_pool uses the ordered property to efficiently implement the automatic destructor calls for allocated objects Sorry to bother you, I have a few more questions on this topic: 1) from what I understand, the ordered property depends on the fact that allocation and deallocation calls are correctly paired, in the sense that if I always call free() in the opposite order of the respective malloc() calls the pool is still considered to be ordered. Is this right? In this special case, would I get a benefit by calling ordered_malloc()/ordered_free()? 2) can ordered_malloc() be called on a non-ordered pool? Does the call make the pool ordered? In this case, is the complexity still O(1)? 3) can ordered_free() be called on a non-ordered pool? Does the call make the pool ordered? 4) ordered_malloc() is described as merges the free list to preserve order, does this mean that unused, but potentially usable, chunks are removed from the free list? I think the order property is very useful and powerful, but it's not terribly clear from the docs how it can be exploited to full potential. The descriptions of the methods are missing post-conditions that are, in my opinion, as important as pre-conditions. Change in the ordered state of the pool could be added more explicitly there. Moreover, if a function can be called on both ordered and un-ordered pools, it would be interesting to state explicitly if there's a difference in behaviour and/or complexity. Thanks for your patience, Alberto Barbati ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regex linking error gcc 2.95 solaris 2.8, stlport
I built the library individually with the following line : bjam -sTOOLS=gcc-stlport -sSTLPORT_ROOT=... everything seems to compile properly but when I use the following from a .so : boost::regex exp(std); I get the following error from dlopen: ld.so.1: output/Text2RvMsg_tester: fatal: relocation error: file output/Text2RvMsg.so: symbol __Q25boostt14reg_expression3ZcZQ25boostt12regex_traits1ZcZQ24_STLt9allocator 1ZcPCcUiRCQ24_STLt9allocator1Zc: referenced symbol not found does anyone know how to get around this? There are similar symbols within the debug.so that I am trying to use however they are usually a regex_traits1ZcZt24 or something similar. I have tried to search for this but can't find a match for it, is it some gcc compilation error? No idea we could use some input from a gcc expert to tell us what that symbol means, just an idea here, but can you not link against the .a lib file - apart from anything else your final code size will be much smaller (including the size of the lib that is). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Possible boost addition: sub string and const string.
Alexei, Looks like we're all thinking alike, a while ago I put together a sequence based substring class that could act as a universal wrapper for any string like object, along with a set of algorithms to act upon it: it's based loosely on Darin Adler's original string algorithm code. classes: string_traits: this is the glue that allows the classes and algorithms to act upon any string like object (std::string, char*, other string classes etc) basic_substring: an immutable view of any string like object (or iterator sequence). Algorithms returning a substring: rtrim ltrim trim Algorithms returning a new string: make_upper make_lower Inplace transformations: inplace_ltrim inplace_rtrim inplace_trim inplace_make_upper inplace_make_lower And then I ran out of time... :-) I've put what I have at http://groups.yahoo.com/group/boost/files/string_algorithm/substring.zip, it's actually pretty complete with full test cases etc, but I'm not sure where this would fit in with the proposed new string lib, plus I'm pretty short of time at present. Still I'm hoping someone can make use of this and maybe the new string lib can include a synthesis of all these ideas... John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Illegal Friend?
According to g++ and comeau, the following is illegal: (The commented line
allows the code to compile.)
class A {
public:
A () {}
~A () {}
private:
class Nested;
//friend class B;
};
class B {
public:
B () {}
~B () {}
private:
friend class A::Nested;
};
Here's why:
7 A name nominated by a friend declaration shall be accessible in the scope
of the class containing the friend declaration.
It is ridiculous that I can't give access to an inaccessible class. You have
to have access to be able to give it? What is the justification for this?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Illegal Friend?
On Sat, Nov 23, 2002 at 10:57:17AM -0500, Eric Woodruff wrote: It is ridiculous that I can't give access to an inaccessible class. You have to have access to be able to give it? What is the justification for this? The reason for making things private is to say this is an implementation detail and I don't want anyone else to depend on its existence. If A were later to remove its internal class, compilation of B would fail. The correct way of doing this I suppose is to make both classes friends of eachother. But best of all would be to not use friends at all. -- Mattias Flodin [EMAIL PROTECTED] - http://www.cs.umu.se/~flodin/ Room NADV 102 Department of Computing Science Umeå University S-901 87 Umeå, Sweden -- Too many errors on one line (make fewer) -- Error message from Apple's MPW C compiler ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Review
Hi,
I've been following the library and the discussion surrounding it since it
was first announced on the list.
I believe it is a very important and much needed component and I thank
Robert for bringing it forward to the boost community!
For the review I have gathered some issues I would like to bring to
attention. (presented in no particular order)
Features / Implementation:
* I haven't seen any reaction on the friend-declaration change needed in
shared_count.hpp to support serialization of shared_ptrs. Would this
coupling shared_ptr-serializer be ok for an official boost release?
Anyhow, I'd like to point out an alternative implementation approach to
handle non-intrusive smart-ptrs (like shared_ptr) in a non-intrusive way ;-)
(I've briefly mentioned this approach in private communication with Robert)
-
The method relies on a map of raw_ptr-shared_ptr that is maintained at
deserialization time.
At load-time the initially empty map is populated with the shared_ptrs that
show up as destination
targets. The code first looks in the map to see if a previous shared_ptr
exists been handled, if so it is initialized by copying from the one in the
map. Only if it's the very first ptr to a new object or the first shared_ptr
a shared_ptr::reset(raw_ptr) is performed, followed by insertion in the map.
This will maintain correct ref-counts for smart-ptrs without knowledge of
internal functionality.
Note that this approach _only_ saves the raw-ptr and nothing else relating
to the shared_ptr to the archive and that it even manages to implicitly
repair faulty shared_ptr links :) . Finally weak_ptrs are easily handled
using the same shared_ptr base.
I have used this implementation in a modified CommonC++ serializer and I
believe it would work as a specialization for shared_ptrT in Roberts
serializer if needed. Altough I'm not 100% sure how much the lack of a
baseclass would complicated matters.
(hmm, hope the above makes alteast some sense.. ;)
-
* I'd like to see a boost::serializer handle all/most of the std/STL and
boost components out-of-the-box.
Even though the current implementation shows how to handle both auto_ptr and
shared_ptr in the examples they're IMO too important not to be included in
the official core-package. Both from a QoI point of view but also purely
convenience.
Structures that come to mind are:
std::auto_ptr
std::stack
std::queue/priority_queue
boost::scoped_ptr
boost::shared/weak_ptr
boost::tuple
boost::array
boost::multi_array
etc ...
* The handling of the different (like the STL) components should be broken
into separate .hpp files.
(altough possibly retaining a convenience wrapper)
* Since the library already supports hash_map and slist etc I guess adding
support for the popular rope string-container would be a simple addition
also.
* Regarding support for serialization of the container adaptors like stack
and queue I propose a solution something like this to be able to take
advantage of possible optimized serialization of the basecontainer. This
example serializes a std::stack at the expense of an extra copying step
which I unfortunately see no conforming way to avoid (since the adaptor
templates are defined to hide the container). Is even this standard
conforming btw? can you assume that the inner-container is always named 'c'?
-
template typename T, class C
struct extract_container_t : std::stackT,C {
typedef std::stackT,C stack_type;
extract_container_t() {}
explicit extract_container_t(const stack_type s) : stack_type(s) {}
const stack_type::container_type get() const { return c; }
stack_type::container_type getref() { return c; }
};
templateclass T, class C
inline void save_template(boost::basic_oarchive ar, const std::stackT,C
t, long) {
ar extract_container_tT,C(t).get();
}
templateclass T, class C
inline void load_template(boost::basic_iarchive ar, std::stackT,C t,
boost::version_type file_version, long) {
extract_container_tT,C tmp;
ar tmp.getref();
t = std::stackT,C(tmp.get());
}
-
* If possible, I'd like to be able to build a version of the library with
disabled exception-handling.
(as several other boost libs already provide)
* If it's possible to simplify the library and/or refactor it into separate
components I'd like to see that.
* nitpick: code cotains some superflous inlines in a couple of places.
Design:
*The core design is the best I've seen of a serializer. The key features:
Non-intrusive serialization (no baseclass!), versioning, standard RTTI and
good STL support. This coupled with being even easier to use in day-to-day
code than for example MFC makes it very attractive in my eyes!
* Q: Regarding serializable structures. How should other boost components
handle interaction with a serializer? Should
Re: [boost] Illegal Friend?
[EMAIL PROTECTED] (Mattias Flodin) writes: On Sat, Nov 23, 2002 at 10:57:17AM -0500, Eric Woodruff wrote: It is ridiculous that I can't give access to an inaccessible class. You have to have access to be able to give it? What is the justification for this? The reason for making things private is to say this is an implementation detail and I don't want anyone else to depend on its existence. If A were later to remove its internal class, compilation of B would fail. The correct way of doing this I suppose is to make both classes friends of eachother. But best of all would be to not use friends at all. This is OFF TOPIC for Boost. Please take your discussion to an appropriate forum such as comp.std.c++. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Sockets
Please feel free to edit the wiki pages with comments, etc. Looks like a nice start. I see you have already captured Beman and others prior work. I have added a references page for pointers to other C++ socket libraries and other references as well as a few other quick thoughts. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?RecentChanges Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Spurious g++ warnings with shared_ptr tests
Can we add -Wno-non-virtual-dtor to g++ tests? The ability of shared_ptr to support nonvirtual destructors is an essential feature, and the tests do exercize it. -- Peter Dimov http://www.pdimov.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: AW: Sockets
On Sat, 23 Nov 2002 19:13:14 +0100, Boris Schäling [EMAIL PROTECTED] wrote: I read your library requirements. Thanks. I don't agree that a socket library should wrap rather than invent. Agreed that the C++ library should leverage the power of C++, but we could do this while remaining in some way familiar. The intent is to provide a clean C++ interface. Certainly at a higher level some form of smart address resolution should be provided, but I don't think that obviates the need for seperate address classes for seperate protocols, for those people who do not want to pay for functionality that they do not need. eg. for address resolution - should it also resolve decnet addresses? osi addreses? Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Sockets
On Sat, 23 Nov 2002 11:18:24 -0700, Jeff Garland [EMAIL PROTECTED] wrote: I see you have already captured Beman and others prior work. I have added a references page for pointers to other C++ socket libraries and other references as well as a few other quick thoughts. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?RecentChanges Jeff, Thanks. As regards times, we should definitely be using the time_duration from boost date_time! Would you have any code references for the usage scenarios that you added ? Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Serialization Library Review
Robert Ramey [EMAIL PROTECTED] writes: Thats all for now. I will have much more to say on this topic in the coming days. Please say it soon, if so. The review period ends on Monday and I'd like to have your information for when I evaluate everything Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: AW: Sockets
At 02:46 PM 11/23/2002, Hugo Duncan wrote: On Sat, 23 Nov 2002 19:13:14 +0100, Boris Schäling [EMAIL PROTECTED] wrote: I read your library requirements. Thanks. I don't agree that a socket library should wrap rather than invent. Agreed that the C++ library should leverage the power of C++, but we could do this while remaining in some way familiar. Yes, that was the intent. I was the author of the original wrap rather than invent wording: Build on the widespread and mature network programming infrastructure which is already in place. Wrap rather than invent. The sockets interface is well known to many programmers, and numerous books, tutorials, and other materials are available. Build on this base, except in cases where it clearly runs counter to good C++ software engineering practice. I'll change the offending sentence to Reuse successful sockets and C++ idioms, rather than inventing new ones. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Sockets
Jeff, Thanks. As regards times, we should definitely be using the time_duration from boost date_time! Yes, but we'll need to do something with the core. If you just used posix_time::time_duration out of the box it is a bit of a heavy dependency for the need. Would you have any code references for the usage scenarios that you added ? No, just some scenarios I thought of -- we would have to write code. Unfortunately, all the 'example' code I have ever written in this area is buried in closed source applications... The other thing is that I expect most of the server examples to be pretty simplistic b/c you usually don't write much in the way of a 'real' server until you have sophisticated dispatching of I/O across multiple sockets or multiple threads. All this is way out of scope for the basic socket class. Of course, given Boost.Threads and Boost.Function you are a long way there... Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AW: [boost] Re: AW: Sockets
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag von Hugo Duncan Gesendet: Samstag, 23. November 2002 20:47 An: [EMAIL PROTECTED] Betreff: [boost] Re: AW: Sockets On Sat, 23 Nov 2002 19:13:14 +0100, Boris Schäling [EMAIL PROTECTED] wrote: I read your library requirements. Thanks. I don't agree that a socket library should wrap rather than invent. Agreed that the C++ library should leverage the power of C++, but we could do this while remaining in some way familiar. The intent is to provide a clean C++ interface. Certainly at a higher level some form of smart address resolution should be provided, but I don't think that obviates the need for seperate address classes for seperate protocols, for those people who do not want to pay for functionality that they do not need. Okay, agreed. As far as I remember former discussions in this list some people supported a select()/poll()/somehow centralized interface others favoured independent socket classes. What about two different socket libraries? One simple select()/poll() based library comparable to ACE following the Reactor pattern and one more complex library with independent classes? A C++-socket library following the Reactor pattern would be much easier to use than select() or poll() in C. Two socket libraries would be comparable to Java where the java.net and java.nio packages provide different approaches to connect to the network. Boris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sockets
I'm interested in participating in the design and implementation of a Sockets library. Your initial documents look like a good start. I have some comments, suggestions, and general ideas about a sockets library. Where should I post these? Should I add them to the Wiki page, or maybe post them to this list? I'm just curious because I haven't participated in Boost development before, and I don't want to choose the wrong forum for my input. Thanks, Rob ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sockets
- Original Message - From: Hugo Duncan [EMAIL PROTECTED] discussions, I have tried to start describing a design at: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket When I look at the examples I'm curious why I see this: socket_base::initialise(); ... socket.close(); socket_base::finalise(); Why doesn't this happen in the constructor/destructor of some object? regards Thorsten Ottosen, AAU ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sockets
On Sat, 23 Nov 2002 14:23:37 -0600, Rob Tougher [EMAIL PROTECTED] wrote: Where should I post these? Wherever you see fit :-) I would suggest the mail list for discussion, and the wiki for capturing points that you don't wan't to get lost. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] How best to use Wiki (was Sockets)
I'm interested in participating in the design and implementation of a Sockets library. Your initial documents look like a good start. Great! You will note that I posted references to your Linux Journal articles :-) http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/References I have some comments, suggestions, and general ideas about a sockets library. Where should I post these? Should I add them to the Wiki page, or maybe post them to this list? I'm just curious because I haven't participated in Boost development before, and I don't want to choose the wrong forum for my input. Well, we are all still feeling our way a bit with the best division of things, but I would recommend the following: 1) If you have some commentary, concepts, or other contributions to add to the current work then just add them to the Wiki and post at least a pointer to the mailing list. Wiki can support ongoing discussions 'thread pages', but it seems to be much better at capturing ideas from a large group of people that have some persistence. Discussion threads are too difficult to manage on 'page'. Of course the Wiki can also have pointers into the mailing list archive so that it is easier to find the discussions. 2) If you have questions or need to start a discussion on a particular topic you should use the mailing list because it more people monitor it than the Wiki. 3) The Wiki is ideally suited for organizing an ongoing work with many participants. Boost.Documentation, for one, has created a task list that scopes out major things and people can sign-up as they can. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Documentation_Format/Tasks We probably should have one of these for Boost.Socket as well -- presuming that this is going to take some time and will have fairly high interest. 4) The MPL team used another Wiki to develop documentation. Not sure how that worked. Aleksey care to comment? Also note that for large efforts I have either helped refactor things so that there is a base page and 'subpages', or we have started that way. This is nice because when you hit the Page List link on the Wiki all the pages related to a particular topic are all together. http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?action=index Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Socket Implemnentation
I have put together an initial implementation in the boost-sandbox. The aim of this code is really just to have something concrete to discuss and to have as a base to experiment on. The implementation more or less reflects the design presented at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket The sandbox contains the simple client and server test shown on the Wiki. At the moment the examples it compiles on: gcc 3.2 cygwin borland Bcc5.5.1 borland Bcc5.6.1 vc7 vc6 sp5 Note the lack of unix :-(, though given the cygwin implementation, it should not be too difficult to get working. Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Library Review
Thomas Matelich wrote: Dirk Gerrits wrote in message ar37hg$6hm$[EMAIL PROTECTED]">news:ar37hg$6hm$[EMAIL PROTECTED]... Thomas Matelich wrote: Anyway, seemed like a nice package for general use. My company is currently in love with XML, so I probably wouldn't be using it for our commercial products. Maybe you missed it due to only skimming the documentation, but it is possible to write your own archive types for use with the library. An XML output archive should be pretty easy, and I imagine that given an XML parser, an input archive should also be quite feasable. I didn't miss it and considered it, but XML usually names its elements. That meta-data is an important part of validation and the free-form lovefest that makes XML popular. There is no way that I saw, given the abstract interface of the archives, to name the string that I put into the archive. Perhaps that could be an extension. Yes, other threads made me realize this. I withdraw my statements. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: AW: Re: AW: Sockets
Boris, On Sat, 23 Nov 2002 21:35:58 +0100, Boris Schäling [EMAIL PROTECTED] wrote: favoured independent socket classes. Not sure what you mean by independent classes? java.net and java.nio packages provide different approaches to Had a quick look at these. Isn't java.nio just a layer on top of jav.net ? Which library corresponds to which usage ? Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: AW: Re: AW: Sockets
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hugo Duncan Sent: Sunday, November 24, 2002 12:11 AM To: [EMAIL PROTECTED] Subject: [boost] Re: AW: Re: AW: Sockets Boris, On Sat, 23 Nov 2002 21:35:58 +0100, Boris Schäling [EMAIL PROTECTED] wrote: favoured independent socket classes. Not sure what you mean by independent classes? Sorry if I wasn't clear. There are several I/O models: 1) blocking 2) multiplexing 3) signal-driven 4) asynchronous In former discussions some people wanted to see a library for 1), others wanted to see a library for 2). The library you propose fits to 1) as far as I can tell. The reason why I proposed two different socket libraries in another mail some hours ago is because of the different models that are possible. As blocking and multiplexing are possibly the most used models Boost should support both. In a multiplexing model the classes need to form a team - someone has to multiplex everything. In a blocking model classes are not dependent on each other: You can use eg. a socket class and don't have to tell another class that it should poll over the socket descriptor. I will try to set up another page at Boost Wiki to explain in detail what I mean by multiplexing library. java.net and java.nio packages provide different approaches to Had a quick look at these. Isn't java.nio just a layer on top of jav.net ? Which library corresponds to which usage ? Oops, I meant java.nio.channels. Classes in java.nio.channels enable application developers to use multiplexing while classes in java.net support blocking model. Boris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] How best to use Wiki (was Sockets)
Jeff Garland [EMAIL PROTECTED] writes: 4) The MPL team used another Wiki to develop documentation. Not sure how that worked. Aleksey care to comment? I can tell you that it ended up being pretty one-sided. It was great for Aleksey - he had the whole Wiki on his local machine and could edit pages in his favorite editor and write new scripts when he wanted to. It was awful for me, to the point where I just never wrote anything in that medium. I have a strong preference for CVS for working on collaborative documentation. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] How best to use Wiki (was Sockets)
David Abrahams wrote: Jeff Garland [EMAIL PROTECTED] writes: 4) The MPL team used another Wiki to develop documentation. Not sure how that worked. Aleksey care to comment? I can tell you that it ended up being pretty one-sided. It was great for Aleksey - he had the whole Wiki on his local machine To clarify - at one point of time; when things were moved to www.mywikinet.com, I lost my privileges :). I'll let Emily speak for herself, but IMO the collaboration part of doing the docs in Wiki works pretty good. The main reason I switched to DocBook later was the lack of the semantic/structural markup and all the nice benefits it brings along (different output formats, automatic TOC generation, better cross-reference capabilities, et al.). and could edit pages in his favorite editor Actually I _always_ edit them in the edit box in browser; it doesn't bother me much. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
