- Boost - lists.boost.org

lists.boost.org not updated
by Peter Dimov 24 Apr '05

24 Apr '05

http://lists.boost.org still links to the old archives. -- Peter Dimov http://www.pdimov.com

1 0

[smart_ptr] sp_counted_base_cw_x86.hpp for release?
by Rene Rivera 24 Apr '05

24 Apr '05

Peter, Should I add the sp_counted_base_cw_x86.hpp implementation in or not? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 3

como toolset failures
by Bronek Kozicki 24 Apr '05

24 Apr '05

I think that big part of failures in como toolset are due to --a (strict mode) option. This unfortunatelly prevents windows headers from being included. Or more precisely, the exact reasult of including windows headers with --a option on is that compiler chokes on __declspec, which is exactly what I see in results. I'd rather not update como toolset to remove this option, maybe someone more familiar with bjam will do this. B.

3 3

Is there an IRC channel discussing boost?
by Schrom, Brian T 24 Apr '05

24 Apr '05

I did a modest amount of Googling and looked through the website for an IRC channel. Did I just miss it, or is there not one? Thanks. Brian S.

3 2

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Michel, >> The reason I suppose that I preferred not-yet-connected >> as a state of stream (vs. a separate class) is that it >> is logically a 1-to-1 relationship (and even the same >> socket) whereas acceptor is a 1-to-N relationship (the >> acceptor socket never becomes something else). > > I don't see connector as 1 to 1 concept. You can use a > connector to establish several connections to the same > address or endpoint if that is needed. The connector > pattern can be used to model fail over between > different endpoints providing the same servcie, by > having a service_connector implementation that wraps > and coordinates several alternate connectors to > different end points over potentially different > transports. This also hides/abstracts the fail over > strategy new endpoint selection in a nice way from > the protocol handler and stream. I see this as something useful, but at higher level than what I am proposing. That may be just because I have never needed anything like it. ;) In all my own uses of connection establishment, it has been one-off connections. Occasionally, I need to reconnect to the same server, but I have always done that with the address object in my proposal. >> The other reason I went with the approach I have is >> that there is only one object to deal with for cancel. >> I don't need to worry about the transition from >> connecting to connected when I want to abort. > > The exact ownership of the socket/handle is always > clear either the connector owns it during the > connection phase and when it's connected the > ownership is transferred to the stream. So I don't > see this as a potential problem. The scenario I am describing goes along with the above statements on single use: I want to do an HTTP get. I first connect, then write, then read. If I decide to cancel, especially with threads in the mix and using blocking style, I must know that I am blocked on the connector, not the stream. But this is not so easy to "know". I cannot hold a lock while I am blocked on connect. What this does is create a race: the entity wanting to cancel cannot know if the blocking call has just finished or not. Which is why I don't like sync programming anymore! ;) I see the granularity as not getting along well with the desire to cancel a specific operation that required a connection. This is especially true for reuse of the connector in the environment I just described. I hope this clarifies my concern. I really feel that a granular cancel feature has to be part of the design. Preferably in a way that is MT friendly. :) > Seperating the connection establishment would make the > stream more stateless and have fewer concerns and it > separates responsibility keeping the interfaces easier. > I also doesn't imply inheritance as is the case whit a > connectable stream. You also don't have to handle > questions such as if a stream can be connected again > after it is closed and so forth (and i guess this could > be different in different implementations). The stream still has many states; this eliminates only one. Also, I don't see any (good<g>) reason to reuse streams. That would be particularly bad in a MT scenario. >> Some platforms have socket features that aren't available >> on other platforms. Unix has signal-driven I/O, while >> Windows does not. Windows has event object based I/O, >> completion ports, HWND messages, etc. which are unique >> to it. The common intersection is blocking, non-blocking >> and select. One can write 99% portable sockets code based >> on that subset. > > So basically layer 0 should support this portable subset. Well, I would mostly agree, but I don't think everyone will. One of the goals several people have expressed is the ability to use level 0 wrappers in non-portable ways. What I am proposing is that there be a level 1 that provides a less bumpy, more easily handled, but conceptually very similar interface. This was another reason I don't have a connector object; that concept has no association with layer 0. > You can define FD_SETSIZE to some arbitrary number. On > my FC1 including select.hpp FD_SETSIZE is 1024 so we > will have to handle arbitrary limits in the interface. > On windows select could be implemented using > WSAEventSelect and WaitForMultipleObjects but this will > have to be cascaded to other threads if the set is to > big and in that case handles can be mixed. So either we > have to cater for arbitrary limits, letting the user > implement on top of the limitst. Or remove arbitrary > limits at cost of complexity and probably increased > threadswitching. On Windows, you cannot increase the fd_set size limit, but I think you are correct on Unix that you can increase it. I have never tried because I wasn't sure if that would require kernel recompile<g> and it wouldn't solve my problem even if it were possible. I would not want to do the thread cascade approach (ala Cygwin). I think a much better approach is what I am proposing: hide this detail completely. I am still scratching around in my head for a way to allow true single threaded use (similar to Peter's net::poll suggestion). > Yes the rules must be really clear, and the library > should probably never hold any kind of lock when > calling a user defined callback since that i > genreally very error prone and deadlock creating, but > this also makes it really hard to implement ;) but > also interesting. Yes, quite "interesting" :) And you can remove the "probably" between the "should" and the "never"... ;) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Use of Other Languages in Boost Tools
by Allen 23 Apr '05

23 Apr '05

Dear All Boosters, I am glad to read about Buildbot on the boost.devel group. It is definitely important for improving the regession test of Boost. However, A question comes into my mind then. As we all known, Boost is a pre-standard versatile C++ library for C++ programmers. Obviously all the Boost libraries are written in C++ themselves. However, for tools used in Boost (such as the Boost.Jam, Boost.Build, Boost.Book, etc.), the point is not clear, for they are not intended to be included or invoked by C++ programs directly. I saw that Buildbot is written almost completely in Python, for example. I am confused that shall we consist of writing all the Boost tools in C++? Or they can be written in any other languages such as shell scripts, Perl, Python, or even Java, C# or whatever convenient? I must declare that I am not a C++ purist or monomania.:) I have no intent to depreciate any of the languages other than C++, nor depreciate any of the valuable work done by Boosters. I just *wonder* what is the distinction between Boost libraries and tools exactly, and whether there is a rule we should follow for the development of Boost tools. For example, we now use the Boost.Jam and Boost.Build for our "official" build system. I believe that the goal of the Boost.Jam and Boost.Build is to provide a convenient, best and "standard" way for building C++ programs. However, as a *tool* (which is different from a *library*), one may not care about what language the Boost.Jam itself is written in. Nevertheless, suppose we were using Java Ant for building later, will it be acceptable? (of course, take Java Ant as an example here may be inappropriate.) The obvious two attitudes I can imagine are: (1) Prohibit *extensive* use of other programming languages in Boost tools, for example writing a complex tool in Python completely. (Convenient and small scripts are acceptable.) For we are establishing the Best Practice *in* C++ and *for* C++. In addition, the tools can be extensible and reusable with an API for C++ programmers as *developers* not just as *end-users*. (2) Allow extensive use of any convenient and reasonable programming languages in Boost tools. Maybe there should be a list for acceptable languages other than C++, for example shell scripts, Perl, Python, Ruby, etc. For they are just *tools*, not C++ *libraries*. They are just black boxes to C++ programmers, and we do *not* provide the tools as an extensible tool platform/framework with API for C++ developers/programmers for further extension or reuse. I tend to support (1), it seems to me more attractive. Boost.Wave is a good example in my opinion. It is both a practical *tool* related to C++ and an excellent extensible and reusable C++ *library*. I know that we should do the correct thing using the appropriate tool. There is no one language can rule them all.:) I am not crazy to imagine rewriting everything using C++. However, I do believe that we should concentrate on developing C++ libraries and *C++ tools* in our C++ Boost Project. As for Buildbot for example, maybe it is unwise to seek for a C++ replacement for it (for interpreted languages / scripts may be the correct choice), however I worry about that it has nothing to do with C++ or most Boost C++ programmers except that it is used by Boost Regression Test. Any comments are welcome, but NO flames or language-wars pls.:) Best regards, Allen

2 1

[ptr_container] more operators?
by Pavel Chikulaev 23 Apr '05

23 Apr '05

Thorsten, So we're going to have comparison operators in ptr_container, despite possible polymorphism-related errors. Let me show you some problems with them: e.g. class Base{}; class Derived : public Base {}; bool operator == (const Base &, const Base &); //Handles correctly Base and Derived //then user add class DerivedAgain : public Derived {}; and forget update operator == then all operations == on DerivedAgain objects will use Derived operator ==. And AFAIK user just can't automate reminder about forgotten operator == without registering DerivedAgain somewhere, so all DerivedAgain wrong comparasions will get green light. And I do believe it's undesirable behavior. My vision of the problem: provide all comparison operators, but with compile-time checking that ensures user defined specialization of some traits class: template<> struct has_proper_polymorphic_equal_operator<Base> { enum { value = true; } }; while by default has_proper_polymorphic_equal_operator<T>::value returns false. Second if you provide comparasion operators (with concept checking or not) it's quite strange that ptr_containers aren't CopyConstructible and Assignable. Using the same technique we can provide them: template<> struct is_clonable<Base> { enum { value = true }; }; template<> struct clone<Base> { Base * do_clone(Base * pb) { return pb->CloneMe(pb); //or any other name } }; And I believe that operator = is much needed than comparison operators in real-life applications. So what do you think? P.S. What do you think about my post Proposal: is_swapable, is_nothrow_swapable, nothrow_swap,swap dated 04/12? -- Pavel Chikulaev

2 3

Any Interest in a 3-D Vector library?
by Stefan Koch 23 Apr '05

23 Apr '05

Any interest in a templatized class for 3-Dimensional vectors? (Similar in style to std::complex or boost math/octonion and math/quaternion.) The most recent uses I have had for it are in ray tracing of scattered light through an experimental setup, and in calculating the bending parameters for a pipe of a certain shape. Basic Features: Constructor and component access. Addition and subtraction of vectors. Multiplying and dividing vectors with scalers. Dot and Cross products of vectors. Length (norm) calculation an conversion to unit vectors. Stream I/O. More Advanced Features: Spherical coordinates Cylindrical coordinates Rotations (around principle axes and general axes) Reflection by a surface Refraction across an interface (Snell's law). Rotations are specified by the axis about which the rotation is to be done, and the angle through which to rotate. There is no support for general rotation matrices. What do you think? Stefan

1 0

[optional] End-of-lines problem.
by Rene Rivera 23 Apr '05

23 Apr '05

Please be careful when "fixing" EOL problems you encounter so as not to create additional ones. This change: http://build.redshift-software.com:9990/changes/514 Caused the EOLs to be duplicated: http://tinyurl.com/b6h3r Causing a variety of failures like this one: http://tinyurl.com/bdqrj -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Michel, > Is it a problem that the special or specific adresses is > represented by different textual representations for > different networks? I guess a textual representation > could be devised that makes these look the same with > some psuedo notation. > Like broadcast tcp:/[broadcast]:1234, > tcp6:/[broadcast]:1234, local tcp:/[local]:1234, > tcp6:/[local]:1234, any > tcp:/[any]:1234, tcp6:/[any]:1234 this would i guess > alleviate some of the eventual problems. The pseudo-tokens would work as long as they weren't ambiguous with allowed machine names in that network. I think a simple layer to register network objects (so you don't get them all linked in<g>), plus a fully general text-to-address object mapping would be a reasonable facility. Again, though, I view this as a (good) simplified use case and would still want control over the life-time of these objects (see other posts for the sad story<g>). I do recognize my concerns here are probably not too common, but all this might mean is that an http_get wrapper would be overloaded on url and address_ptr. The former would call the later after a lookup. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1