- Boost - lists.boost.org

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

10 Mar '05

On Wed, 2005-03-09 at 10:22 -0500, Caleb Epstein wrote: > On Wed, 9 Mar 2005 08:45:52 +0000 (UTC), Jarl Lindrud > <jlindrud(a)hotmail.com> wrote: > > > > As for messaging vs RPC, I think the same thing applies; it is easier to > > > build an RPC layer on top of messaging than the other way around. > > > > If you have oneway RPC's, why would it be difficult to build messaging on top of > > that? The two seem to me to be almost the same thing. > > Messaging is often built on top of a broadcast or multicast transport, > so one does not need to locate or connect to a remote endpoint in > order to publish messages. In most, if not all messaging systems you do have connect to an end point. The remote server provides various QoS and you need to register your subject or channel and whether you are a push or a pull publisher. Oh 8-) I think I'm re-inventing the CORBA Notification service. What a surprise. > I don't think one-way RPCs are an adequate > replacement for publish-subscribe semantics like these if you have a > large fanout. Simple one-way RPCs don't have a return value and can't throw exceptions an so there not a good way for messaging if you want QoS other than best efforts. The fan out is irrelevant using multi-cast. /ikh

4 3

looking for Dietmar's thesis
by Max Khesin 09 Mar '05

09 Mar '05

Does anyone have a copy of Dietmar Kuehl's Master's thesis stashed somewhere? The ftp link is dead, and I cannot find mine. thanks, max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

[shmem] Uploaded to Vault+documentation questions+misc
by ION_G_M 09 Mar '05

09 Mar '05

Hi James and all shmem users, Sorry for uploading to boost files but I had some problems with file size, so I uploaded to boost files instead. In boost vault you will fine a new folder (Shmem) with 3 new files: Shmem.2005-03-06.tar.bz2 //library Shmem.2005-03-06-doc-1.tar.bz2 //doc1 Shmem.2005-03-06-doc-2.tar.bz2 //doc2 Write now I am writing documentation with a text editor and it's just a pain. For this version, I've discovered the CDATA usage so I don't have to manually escape XML characters (<, >, &). I will have a look at Quickbook. Is there any way to "insert" a cpp file directly on the code using BoostBook/QuickBook? That would help me a lot to mantain example code without errors. I've also seen in unordered associative containers documentation that colored code is used and I'm very interested in that, but I don't know if that is provided by BoostBook or was created with an external tool. Regarding new version, there are some name changes, so please, forgive me. I don't plan any further name changes except after a boost review. I've tested it in Windows XP using visual 7.1 mainly and Linux 2.6 kernel (Suse 9.2) using gcc 3.4.1. But it's possible to be errors in some linux tests. For this version I don't have any atomic swap/inc/test function and I don't plan to have it, because library has grown so much that I prefer to polish a bit this. I agree that those functions would be very useful to implement lock-free allocators and structures. If win32 shared_mutex/shared_condition seem very rudimentary test/yield functions but I've not found any pthread-like process shared mutex/condition implementation in any place (the latest time I checked, cygwin, pthread-win32, Windows Unix Services, didn't support that) so I had to make this hack to go on. When I propose a review process, surely synchronization objects should be included/adapted to boost threads, but currently boost::thread's elements don't allow single threaded builds, so I can't use boost::xtime and scoped_locks in shmem when synchronizing two single threaded processes. That's why I've copied those classes in my library changing their name. One last thing: shared memory creation/destruction is not very portable, because I can't find a common implementation that suits win32/posix shared memory model (I mean shm_unlink behaviour). I've not found any valid implementation except using System V shared memory to emulate Win32 shared memory, but I want to use posix functions if available. Has anyone solved this before? Well, thank you for your comments and feel free to write if any problem is found. Regards, Ion

5 5

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

09 Mar '05

In-Reply-To: <d0kr8r$gl6$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > It's a pleasure to announce that the review of Daniel James' hash > functions library starts today (8th of March) and ends the 12th > of March. I have some questions about the design. First, why does hash_combine have a void result, and have side-effects on its arguments? Wouldn't a pure, side-effect free function be better? Second, why doesn't hash_range depend on the length of the sequence? For example, the hash_range of { 12 } and { 0, 0, 0, 12 } are the same. I'd rather they gave different results. Thirdly, the hash values love producing 0. For example, hash_value( (char *) NULL ) and hash_value( false ) are both 0. hash_combine on a range of 0s will produce another 0. Am I the only person who sees this as a problem? -- Dave Harris, Nottingham, UK

2 1

[Boost-bugs] [ boost-Patches-1160158 ] Perl style foreach iterating
by SourceForge.net 09 Mar '05

09 Mar '05

Patches item #1160158, was opened at 2005-03-09 20:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1160158&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amir Taaki (genjix) Assigned to: Nobody/Anonymous (nobody) Summary: Perl style foreach iterating Initial Comment: somewhere in boost, there should be a perl style foreach iterator, like so #define ITERATOR(obj) typeof(obj.begin()) #define foreach(v,i) for(ITERATOR(v) i = v.begin() ; i != v.end() ; i++) genjix at gmail.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1160158&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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