March 2005 - Boost - lists.boost.org

offline code generator for BIL
by christopher diggins 09 Mar '05

09 Mar '05

I just wanted to put forth that I really could use an offline code generator for my work on the OOTL. I only want a handful of interfaces for the library which won't change often. The benefits for me are: a) I won't have extra boost dependencies for meta-programming b) have the fastest possible compile times for my library Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

3 5

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 09 Mar '05

09 Mar '05

In-Reply-To: <422EFC7F.9D48D181(a)tid.es> joaquin(a)tid.es (=?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?=) wrote (abridged): > Oh, sorry, I misread it. I agree with you hashing a bool makes little > sense, and agree that it probably shouldn't be made part of the public > interface (for the same reasons, for instance, that there's no overload > for char.) Is that because bools and chars will be promoted to ints? I can imagine wanting bools and chars to hash differently, to take advantage of their special properties. Then hash_value('\0') could be different to hash_value(0), which wouldn't bother me because they are different types. However I can understand if this is felt too risky for general use. -- Dave Harris, Nottingham, UK

1 0

Re: [review] hash functions
by Jaap Suter 09 Mar '05

09 Mar '05

I would like to second the following: "1. The overloads of hash_value for STL containers forces the implementation to include <vector>, <list>, etc., which makes the header a little heavier than desired." I'd say it's not a 'little' heavier but a lot heavier. Can we not put the extensions in their own header files; vector_hash.hpp or something? Not everybody has all these containers in a precompiled header already. Thanks, Jaap Suter

3 2

Logo Contest Current Tally
by Joel de Guzman 09 Mar '05

09 Mar '05

Hi, You can see the latest logo contest tally here: http://boost.org/more/logo_contest_tally.htm As of March 7, 2005: Votes Entry 6 38, Simeon Nasilowski 5 67, Simeon Nasilowski 4 39, Simeon Nasilowski 4 75, Zoltan "cad" Juhasz 3 83, Emil Kirichev 3 85, Ben Hetland 3 92, Aleksey Gurtovoy 2 18, Boost 2 Jonathan Turkanis 2 52, Zoltan "cad" Juhasz 2 60, Banu Alexandru 2 68, Aleksey Gurtovoy 1 1, Boost 1 13, René Rivera 1 20, Jonathan Turkanis 1 23, Jonathan Turkanis 1 29, Erik Wien 1 3, Joaquín M López Muñoz 1 30, Erik Wien 1 62, Mike H 1 97, Jonathan Turkanis 1 18, Jonathan Turkanis Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

15 39

Re: [boost] Re: RPC library
by Iain Hanson 09 Mar '05

09 Mar '05

On Thu, 2005-03-03 at 22:28 +0000, Jarl Lindrud wrote: > Iain Hanson <Iain.Hanson <at> videonetworks.com> writes: > > [snip] > You're making my point for me. For something quick and dirty, who is going to > want to type all that out? And before I do, I have to learn about IDL, _var > types, safe downcasts, factories, CORBA::string's, etc, while in the back of my > mind there's the nagging suspicion that I've missed some subtle detail > somewhere. I hardly find 5 lines of code onerous. And it is easy to wrap up part of it in a template. Quick and dirty may be something you do to learn how to do something. But AFAIK, not something we create boost libraries for. IDL is what gives you type safety, something we usually appreciate in C++. > And whoever will be looking at my code needs to learn these things as > well. This is something that never fails to amaze me. Building distributed systems is hard to do correctly. It is very similar to the difficulty with threaded systems but the issues are subtly different and I think harder in distributed systems. If you can't learn a few conventions in half a day, then you probably have no business trying to build such systems. I probably spend half of my working life fixing systems that have been quickly hacked and then put into production. CORBA /EJB both have marketed themselves as the easy and safe way to write distributed systems and they are not. They are easy to write bad systems in. What you are proposing is an easier way to write even worse systems. > I also have to modify the build process to handle the IDL files, and then > find an ORB to build and link to. None of this is difficult, but I personally > find it rather cumbersome, and above all, for my situation it's just plain > unnecessary. All I wanted to do was to make a couple of remote calls between two > C++ programs! Something along these lines seems to me much more proportional to > the task at hand: You already have to link to the serialization library that you have had to build. I don't understand the difference. And your user needs to understand the trade-offs with each archive format. > > // server > > RCF_BEGIN(I_Echo, "I_Echo") > RCF_METHOD_R1(std::string, echo, std::string); > RCF_END(I_X); > > struct Echo > { > void std::string echo(std::string s) { return s; } > }; > > int main() > { > RCF::RcfServer server(50001); > server.bind<I_Echo,Echo>(); > server.start(); > return 0; > } > > // client > > RCF_BEGIN(I_Echo, "I_Echo") > RCF_METHOD_R1(std::string, echo, std::string); > RCF_END(I_Echo); > > int main() > { > std::cout << RcfClient<I_Echo>("localhost", 50001).echo("ho hum"); > return 0; > } > Your client has 4 lines of code to my 5 and you have macros in your interface. Not normally considered a good thing. And you have hard coded the server location. Always considered a bad thing in anything but toy code. [snip] > I guess the argument boils down to this: does anyone write network applications > for which CORBA-style scaleability is not a requirement? I would think so, but > maybe I'm wrong. > There are low level systems that need to work with sockets. The IETF has made a pretty good job of making the internet protocols scale. And there are hard and soft real time projects that need to use sockets. There are probably a lot of applications that have been built using sockets that should have used CORBA. Cost has historically been a big issue with CORBA because commercial implementations have typically ( in the U.K. ) cost of the order of £3,500 per developer a year and £2,500 per user a year run time. > RPC's don't scale too well, we both agree on that. But why do you think all > applications need to scale? If I'm prototyping something, then the last thing in > the world I need is scaleability, and I certainly wouldn't want the development > cluttered and slowed because someone has decreed that we must all use CORBA > because it scales so well. > If you are just playing around then I don't have a problem. But I don't think boost is in the habit of adopting toys. The problem with over simplified solutions is that a prototype is built, the boss asks for a few extra features, and before you know it, its rolled out to production and know one will pay for it to be re-written properly :-(. > Your position seems to be that programmers should not be afforded the option of > choosing; they should just bite the bullet and always use CORBA. If they don't > like that, then they should just avoid networking altogether. Personally I tend to prefer not letting programmers shoot themselves in the foot, if I can avoid it. Unfortunately, they ( and I sometimes ) are incredibly inventive at finding new ways to do so ;-). /ikh

7 11

N-arity operators in C++, also reducing temporaries. [Repost]
by Pavel Chikulaev 09 Mar '05

09 Mar '05

This text not as silly as my "Herb Sutter's operator = can be optimized", so please read it. I'm currently working on library "Lazy" which eases creation of classes which needs lazy evalution and n-arity operators to improve speed. The library's sample usage placed below. Please let me know what do you think about it. I'll appreciate any feedback on my library. Library description: Library eases creation of classes which needs lazy evalution and n-arity operators. Library features are: * n-arity operators support; * operator aliasing, such as a + -b will be computed as a - b; * custom operators; * no unnecessary temporaries during evalution and assigning. Library's sample usage: //Matrix.h #include "lazy.hpp" class transpose_tag {}; //Tag class class Matrix { LAZY_CLASS(Matrix) static lazy::type<Matrix> Matrix_; //Similar to Andrei Alexandrescu's Type2Type template public: Matrix(); Matrix(const Matrix &); Matrix & operator = (const Matrix &); void swap(void Matrix &); //Libray won't work without swap function. //If name of your swap function isn't swap then use //LAZY_CLASS_EX(Matrix, YourSwapFunctionName) //lazy constuctors which enables lazy operators Matrix(LAZY_OP(Matix_ + Matrix_)); //Matrix operator +(Matrix, Matrix) Matrix(LAZY_OP(Matrix_ * Matrix_)); //... Matrix(LAZY_OP(-Matrix_); Matrix(LAZY_OP(Matrix_ + Matrix_ * Matrix_)); //ternary operator //Now enable operators LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ * Matrix_); LAZY_ENABLE_OP(Matrix_ = -Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_ * Matrix_); //operator aliasing LAZY_ALIAS(Matrix + -Matrix_ = Matrix_ - Matrix_); //Custom operation Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_))); LAZY_ENABLE_CUSTOM_OP(transpose, Matrix_ = lazy::custom_op<transpose_tag>(Matrix_)); //same as Matrix transpose (const Matrix &) but there //won't be any temporary objects at all }; //Matrix.cpp Matrix::Matrix(LAZY_OP(Matix_ + Matrix_) op) { //Construct matrix object //lhs matrix = op._1 //rhs matrix = op._2 } Matrix::Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_) op) { //Construct matrix object tranposed to op._1 } //etc //Now the use of Matrix class Matrix a, b, c, d; //... a = b + c; //No tempories at all //Using normal practice it will take two temporary objects (no NRVO or RVO ) a = b + -c; //Will be evaluates as a = b - c; No temporaries again //Using normal practice it will take three temporary objects (no NRVO or RVO) a = b + c * d; //Will use ternary operator. No temporaries again a = transpose(b); //Custom lazy operation. No tempories again Maybe the library is very similar to uBLAS's matrix_expression and vector_expression. But with my approach there is no need to code matrix_expression and vector_expression at all and it is easy to create new classes which needs lazy evaluation and n-arity operators. I believe that my library should be very useful with big_int. So what do you think? Is there any similar approaches available? Is there any need of such library? Thanks in advance. -- Pavel Chikulaev

7 47

Herb Sutter's Assignment operator can be optimized + Proposal for very small boost utility library
by Pavel Chikulaev 09 Mar '05

09 Mar '05

Hi, Do you know that well-known Herb Sutter's assignment operator in most cases does unnecessary copying? No? Then read it to learn how to elminate it. class Matrix { //.... Matrix& operator = (const Matrix& that) { Matrixtemp(that); swap(temp); return *this; } //... }; Consider first example: Matrixa, b; //.... a = b; Here Herb Sutter's operator = works just fine. But consider second example: Matrix func (); Matrix a; //... Matrix = func(); Result of func() is copied to temporary objectand then operator = copies it again. So assigning to result of function creates one useless object. Elminating of temporary int object will cost nothing, but elminating of temporary std::vector of 10000 elements will cost a lot. But how can we define that copying is necessary? - Every function returns object not of type T but temporary object of type T. So let's code something: template<typename T> struct temporary : T { temporary() {} temporary(const T & t) : T(t) {} //some operators and constructors to create base object in-place not listed here }; Now let's change function consider operator +: Matrix operator + (const Matrix & a, const Matrix & b) { Matrix temp(a); temp += b; return temp; } To optimize it we do the following: temporary<Matrix> operator + (const Matrix & a, const Matrix & b) { Matrix temp(a); temp += b; return temp; } Maybe it can be hardly optimized using NRVO, so let's help the complier rewriting as following: temporary<Matrix> operator + (const Matrix & a, const Matrix & b) { temporary<Matrix> temp(a); temp += b; return temp; } By now, even returning temporary<Matrix> instead of Matrix, no optimization is done. To enable the optimization we need to change the class Matrix by adding one more assignment operator : Matrix & operator = (const temporary<Matrix> & that) { swap (const_cast<Matrix &>(static_cast<const Matrix &>(that))); return *this; } or using "deprecated" casts Matrix & operator = (const temporary<Matrix> & that) { swap ((Matrix &) that); return *this; } By now we've elminated unnecassary copying. Is this worth being called Pavel Chikulaev's temporary assignment operator? Is this worth being included in Boost? By including temporary.hpp, adding one operator in class, and replacing each function result to explicitly marked temporary you get really a lot. My temporary assignment operator as safe as Herb Sutter's. Maybe returing temporary<T> will make some obstacles to templated programming, so i'm going to add temporary_traits: is_temporary, add_temporary, remove_temporary. Some changes of BOOST_TYPEOF will be also needed. So, what do you think? Copyright 2005 Pavel Chikulaev. Use, modification, and distribution are subject to the Boost Software License, Version 1.0

12 29

Sockets
by Boris 09 Mar '05

09 Mar '05

There hasn't been much talk about a socket library recently. The Wiki stuff about sockets is quite old so I don't know if Hugo is still working on it? It's some time ago I added some proposals for a multiplexing library to the Wiki. So I went through most of the Wiki pages of Boost.Socket and Multiplexing and tried to gather and sort the ideas a bit. As I don't want to go even more into details by adding more C++ code I tried a top-down-approach using UML diagrams. Without sorting the ideas and getting a big picture we are stuck in the details and don't proceed. The network API isn't small, there are many different goals to reach and the network library might overlap with other libraries - quite a lot to do. :-) So here is the next small step: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet As usual any comments are appreciated, Boris

7 13

Boost 1.32.0 and VS.NET 2005 under AMD64
by p.klotz＠icoserve.com 09 Mar '05

09 Mar '05

Hi I have sent a mail about this topic to boost-users a few weeks ago but got no response. There exist a few problems when trying to compile Boost 1.32.0 under AMD64 with VS.NET 2005: * No toolset exists to compile Boost 1.32.0 native on the AMD64 platform (no cross compile). The attached file vc-8_0-amd64-tools.jam fixes that. * InterlockedExchange() in line 44 of lwm_win32.hpp collides with a macro of the same name in WinBase.h One finds in WinBase.h: #elif defined(_M_AMD64) && !defined(RC_INVOKED) ... #define InterlockedExchange _InterlockedExchange I changed the name of Boost's function to InterlockedExchangeBoost() to avoid this problem. * No type long_type exists when compiling with the Microsoft Compiler. The 64Bit part in lwm_win32.hpp seems to have been written for the Intel Compiler. An additional #ifdef now checks if the 64Bit compiler is from Intel or Microsoft. The InterlockedExchange() and long_type issues are fixed by boost_1_32_0-AMD64.patch. Maybe these changes can be integrated in some form in the next version of Boost. Best regards, Peter.

2 2

Re: [boost] [1.33.0]: Some Moderation Please.
by Dave Gomboc 09 Mar '05

09 Mar '05

> Date: Tue, 08 Mar 2005 13:50:54 -0700 > From: "Victor A. Wagner Jr." <vawjr(a)rudbek.com> > > And I _hope_ what I put in the <hostile>...</hostile> was offensive, > it was intended to be. I'd hate to think that I'm accidently offensive > but can't be when I want to. Victor, please, quit while you're behind. Dave

1 0