RE: [boost] Re: binding
Is there a way of using ptr_fun on a method (class instance's function) ?
It can come in very useful
-Original Message-
From: Amélie et François Dumont [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 08, 2003 5:01 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [boost] Re: binding
Just a little remark about the code that has nothing to do with the bug that
has been elucidated by Graig Henderson. When Greg Dehaas wrote:
> I have a namespace GenAlg with this inside:
>
> namespace GenAlg
> {
> template
> unsigned long RouletteWheel(TController *oController)
> {
> ...
> }
> }
>
>
> elsewhere I have a
>
> boost::function1 fncSelection;
>
>
> I try to set fncSelection to RouletteWheel like so:
>
> fncSelection = boost::bind(GenAlg::RouletteWheel long>,_1);
>
>
It seems to me that it would have been more accurate to write:
fncSelection = boost::ptr_fun(GenAlg::RouletteWheel);
there is no use for the boost::bind function even if the result is finally
the same ;-)
___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: binding
Unfortunately, just using &functionname doesnt work on template functions ( fncSelection = &GenAlg::RouletteWheel; ) I tried it and it gets confused about the template parameters (thinks there are different possible functions) boost::ptr_fun works fine though.. Thanx I really could have used that function earlier on! -Original Message- From: Peter Dimov [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 08, 2003 5:27 PM To: Boost mailing list Subject: Re: [boost] Re: binding Amélie et François Dumont wrote: > Just a little remark about the code that has nothing to do with the > bug that has been elucidated by Graig Henderson. When Greg Dehaas > wrote: [...] >> fncSelection = boost::bind(GenAlg::RouletteWheel> unsigned long>,_1); > > It seems to me that it would have been more accurate to write: > > fncSelection = boost::ptr_fun(GenAlg::RouletteWheel unsigned long>); > > there is no use for the boost::bind function even if the result is > finally the same ;-) There's no need to use ptr_fun, either. fncSelection = &GenAlg::RouletteWheel; ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Reflection system in C++ using templates
"Lin Xu" <[EMAIL PROTECTED]> writes:
> I've done some searching on the boost dev list archives, and I've seen
> some interest in a reflection system in C++. I've implemented a full
> reflection system - not only "properties" but functions as well - in
> compile time. There is no storage cost or runtime cost (on MSVC7, the
> assembly isntructions are the same - I haven't checked on
> others). It's also possible to implement runtime reflection too, but
> this would bring a runtime cost. I wish to implement compiletime
> first, then use that to build runtime.
>
> Mainly, I use templates to implement 'properties'. the syntax I would
> forsee is something like this:
> struct A {
> int z;
> int getz() const {return z;}
> void setz(int k) {z = k;}
> void print() {cout << z << endl;}
> };
> namespace Prop {
> struct val {};
> struct print {};
> struct val2 {};
> }
> template <> struct Reflect {
> typedef Implements<
> Prop::val, GetSetPair,
> Prop::print, Function::MemberFun,
> //another way of accessing z, without get/setters:
> Prop::val2, Member,
> //read only (even could be write-only!)
> Prop::val3, GetSet >
>>Info;
> };
>
> That's the basic sytnax. This *could* be done using an automated
> parser, but there's certain things that the system can do that if
> you do by hand, you can do.
But you can't do that ;-)
In particular, MemberFun is incompatible with, say,
MemberFun. You'd need something more like:
MemberFun
MemberFun
Sad but true :(
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Reflection system in C++ using templates
I've done some searching on the boost dev list archives, and I've seen some
interest in a reflection system in C++. I've implemented a full reflection
system - not only "properties" but functions as well - in compile time.
There is no storage cost or runtime cost (on MSVC7, the assembly
isntructions are the same - I haven't checked on others). It's also possible
to implement runtime reflection too, but this would bring a runtime cost. I
wish to implement compiletime first, then use that to build runtime.
Mainly, I use templates to implement 'properties'. the syntax I would forsee
is something like this:
struct A {
int z;
int getz() const {return z;}
void setz(int k) {z = k;}
void print() {cout << z << endl;}
};
namespace Prop {
struct val {};
struct print {};
struct val2 {};
}
template <> struct Reflect {
typedef Implements<
Prop::val, GetSetPair,
Prop::print, Function::MemberFun,
//another way of accessing z, without get/setters:
Prop::val2, Member,
//read only (even could be write-only!)
Prop::val3, GetSet >
Info;
};
That's the basic sytnax. This *could* be done using an automated parser, but
there's certain things that the system can do that if you do by hand, you
can do.
For instance, you can have a virtual get/set pair, and have the proeprty
correctly dispatch to the virtual function from a base pointer. You can
inherit properties (...Prop::Inherit, InheritsFrom...). You can
also have the type of a property be different from the get/set:
...GetSet,Setter >...
Although I'm not sure what use this could be. Similiarly, there is a lot of
flexibility with an function reflection definition.
It enforces access specifier (private/public/protected) distinctions, but in
a previous version I was able to access the internal private data members
(again at compile time). But now I can't because I use member pointers.
There are more interesting things that it can do too, like provide an
"interface" / "implementation" distinction (define a subset of the full
reflection for say serialization - I know there was some discussion about
that). This can be useful, for providing a kind of interface analogy from
java. Functions can act on classes generically, wihtout knowing the true
implementation name, type, or (get/set) vs. (public member). The code is the
same as hand-written though on full optimization. If the types must be
converted, an handwritten bit of codee would similiarly have to do that.
As far as I can tell, there are no 'gotcha's in the implementation, and it's
fairly clean - the only problem is a lot of boost preprocessor code to avoid
PTS. It should work on MSVC6 sp5 (I did not use PTS) and does on MSVC7 and
gcc.
However, if there is more interest I will elaborate further, mainly because
this email is getting far too long already. Any interest? I know the naming
/ coding style is certainly not up to boost standards, but I'm willing to
make it work :)
Thanks.
Lin Xu.
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost_signals.dll contains no symbols
Hello, I just compiled build 1.29 with MS Visual C++ 6, and one of the libraries, boost_signals.dll does not export any symbols (and, as a consequence, no corresponding .LIB file is generated). Is that normal? A library with no symbols is quite useless, no? Anyhow, I'm not really using the signals library, nor I have the time to investigate, I just thought I'd let somebody know, because it seems suspicous. Also, why do some library names start with 'lib' ( libboost_thread.* ), while others do not ( 'boost_threadmon.dll' )? Thanks, D.P. _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: A new boost::thread implementation?
> -Original Message- > From: William E. Kempf [mailto:[EMAIL PROTECTED]] > > > .. borrowing Dave's async_call syntax and Alexander's > > semantics (which aren't really any different to yours): > > Dave's semantics certainly *were* different from mine (and the Futures > link posted by Alexander). In fact, I see Alexander's post as > strengthening my argument for semantics different from Dave's. Which > leaves us with my semantics (mostly), but some room left to argue the > syntax. Isn't that what I said? In any case it is what I meant :-) > > > async_call later1(foo, a, b, c); > > async_call later2(foo, d, e, f); > > thread_pool pool; > > pool.dispatch(later1); > > pool.dispatch(later2); > > d = later1.result() + later2.result(); > > You've not used Dave's semantics, but mine (with the variation of when you > bind). Yes - I thought I said I was using Alexander's/your semantics? Anyway the result is it looks to me like we agree - so I'll go back to lurking... > > >> More importantly, if you really don't like the syntax of my design, it > > at > >> least allows you to *trivially* implement your design. Sometimes > > there's > >> something to be said for being "lower level". > > > > Well as a user I'd be *trivially* implementing something to produce the > > above. Do-able I think (after I have a bit of a look at the innards of > > bind), but its hardly trivial. > > The only thing that's not trivial with your syntax changes above is > dealing with the requisite reference semantics with out requiring dynamic > memory allocation. But I think I can work around that. If people prefer > the early/static binding, I can work on this design. I think it's a > little less flexible, but won't argue that point if people prefer it. I'm not sure that it is flexible enough for everyone - I was just putting up a "what one user would like" argument. I see that Dave wants results obtained from/as a function object for a start - and I'm prepared to believe that that is more important than whether the syntax is a little odd/inside-out at first glance. Regards Darryl Green. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [base_from_member] Members constructed using pass by value
Just ran into a problem using utility::base_from_member. The problem
occurs in the forwarding of constructor arguments to the 'member'. The
base_from_member get these arguments using pass by value.
From the implementation we have:
template< typename T1 >
explicit base_from_member( T1 x1 )
: member( x1 )
{}
etc
I would suggest changing this to pass by reference, that is:
template< typename T1 >
explicit base_from_member( const T1& x1 )
: member( x1 )
{}
etc
There seem to be several good reasons for changing to pass by reference:
1. It is more transparent to the 'member'.
The pass by value in the base_from_member constructor copies it
arguments before 'member' sees them. The actual parameter passed to
'member' is a temporay. If 'member' is actual storing a reference to
argument, the reference will be to the temporary and will thus fail.
2. The additional copy put additional requirements on 'members'
arguments types. They may not actually be copiable!
3. The runtime cost of the copy.
Hopefully there are no disadvanatage!
Michael Stevens
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A new boost::thread implementation?
"William E. Kempf" <[EMAIL PROTECTED]> writes: >> I don't care if you have an "uninitialized" optional internally to the >> future. The point is to encapsulate that mess so the user doesn't have >> to look at it, read its documentation, etc. > > I think there's some serious misunderstanding here. I never said the user > would use optional<> directly, I said I'd use it in the implementation of > this "async" concept. So, we're in violent agreement? Yes, apparently there *is* some serious misunderstanding! When did you say you were talking about the implementation details, and how did I miss it? I thought I've been very clear that I was talking about high-level interface issues. Did you miss that? >>> I *think* I understand what you're saying. So, the interface would be >>> more something like: >>> >>> future f1 = thread_executor(foo, a, b, c); >>> thread_pool pool; >>> future f2 = thread_pool_executor(pool, foo, d, e, f); >>> double d = f1.get() + f2.get(); >>> >>> This puts a lot more work on the creation of "executors" (they'll have >>> to obey a more complex interface design than just "anything that can >>> invoke a function object"), but I can see the merits. Is this >>> actually what you had in mind? >> >> Something very much along those lines. I would very much prefer to >> access the value of the future with its operator(), because we have lots >> of nice mechanisms that work on function-like objects; to use get you'd >> need to go through mem_fn/bind, and according to Peter we >> wouldn't be able to directly get such a function object from a future >> rvalue. > > Hmmm... OK, more pieces are falling into place. I think the f() syntax > conveys something that's not the case, but I won't argue the utility of > it. I understand your concern. Another possible interface that is "functional in nature" would be: future f1 = thread_executor(foo, a, b, c); thread_pool pool; future f2 = thread_pool_executor(pool, foo, d, e, f); double d = async_result(f1) + async_result(f2); Where async_result would be a function object instance. That may seem radical to you, but I think Joel has demonstrated the effectiveness of that approach in Spirit. > Only if you have a clearly defined "default case". Someone doing a > lot of client/server development might argue with you about thread > creation being a better default than RPC calling, or even > thread_pool usage. Yes, they certainly might. Check out the systems that have been implemented in Erlang with great success and get back to me ;-) >>> >>> Taking a chapter out of Alexander's book? >> >> Ooooh, touché! ;-) >> >> Actually I think it's only fair to answer speculation about what >> people will like with a reference to real, successful systems. > > I'd agree with that, but the link you gave led me down a VERY long > research path, and I'm in a time crunch right now ;). Maybe a short code > example or a more specific link would have helped. Sorry, I don't have one. Oh, maybe http://ll2.ai.mit.edu/talks/armstrong.pdf, which includes the "fabulous 10 minute Erlang course" would help. The point is, they use Erlang (a functional language) to build massively concurrent, threaded systems. Erlang is running some major telephone switches in Europe. >> I'm not yet wedded to a particular design choice, though I am getting >> closer; I hope you don't think that's a cop-out. What I'm aiming for is >> a particular set of design requirements: > > Not a cop-out, though I wasn't asking for a final design from you. > >> 1. Simple syntax, for some definition of "simple". >> 2. A way, that looks like a function call, to create a future >> 3. A way, that looks like a function call, to get the value of a future > > These requirements help me a lot. Thanks. No prob. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A new boost::thread implementation?
"William E. Kempf" <[EMAIL PROTECTED]> writes: >> I don't care if you have an "uninitialized" optional internally to the >> future. The point is to encapsulate that mess so the user doesn't have >> to look at it, read its documentation, etc. > > I think there's some serious misunderstanding here. I never said the user > would use optional<> directly, I said I'd use it in the implementation of > this "async" concept. So, we're in violent agreement? Yes, apparently there *is* some serious misunderstanding! When did you say you were talking about the implementation details, and how did I miss it? I thought I've been very clear that I was talking about high-level interface issues. Did you miss that? >>> I *think* I understand what you're saying. So, the interface would be >>> more something like: >>> >>> future f1 = thread_executor(foo, a, b, c); >>> thread_pool pool; >>> future f2 = thread_pool_executor(pool, foo, d, e, f); >>> double d = f1.get() + f2.get(); >>> >>> This puts a lot more work on the creation of "executors" (they'll have >>> to obey a more complex interface design than just "anything that can >>> invoke a function object"), but I can see the merits. Is this >>> actually what you had in mind? >> >> Something very much along those lines. I would very much prefer to >> access the value of the future with its operator(), because we have lots >> of nice mechanisms that work on function-like objects; to use get you'd >> need to go through mem_fn/bind, and according to Peter we >> wouldn't be able to directly get such a function object from a future >> rvalue. > > Hmmm... OK, more pieces are falling into place. I think the f() syntax > conveys something that's not the case, but I won't argue the utility of > it. I understand your concern. Another possible interface that is "functional in nature" would be: future f1 = thread_executor(foo, a, b, c); thread_pool pool; future f2 = thread_pool_executor(pool, foo, d, e, f); double d = async_result(f1) + async_result(f2); Where async_result would be a function object instance. That may seem radical to you, but I think Joel has demonstrated the effectiveness of that approach in Spirit. > Only if you have a clearly defined "default case". Someone doing a > lot of client/server development might argue with you about thread > creation being a better default than RPC calling, or even > thread_pool usage. Yes, they certainly might. Check out the systems that have been implemented in Erlang with great success and get back to me ;-) >>> >>> Taking a chapter out of Alexander's book? >> >> Ooooh, touché! ;-) >> >> Actually I think it's only fair to answer speculation about what >> people will like with a reference to real, successful systems. > > I'd agree with that, but the link you gave led me down a VERY long > research path, and I'm in a time crunch right now ;). Maybe a short code > example or a more specific link would have helped. Sorry, I don't have one. Oh, maybe http://ll2.ai.mit.edu/talks/armstrong.pdf, which includes the "fabulous 10 minute Erlang course" would help. The point is, they use Erlang (a functional language) to build massively concurrent, threaded systems. Erlang is running some major telephone switches in Europe. >> I'm not yet wedded to a particular design choice, though I am getting >> closer; I hope you don't think that's a cop-out. What I'm aiming for is >> a particular set of design requirements: > > Not a cop-out, though I wasn't asking for a final design from you. > >> 1. Simple syntax, for some definition of "simple". >> 2. A way, that looks like a function call, to create a future >> 3. A way, that looks like a function call, to get the value of a future > > These requirements help me a lot. Thanks. No prob. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::format named parameters
Has there been any consderation given to the use of named parameters
with boost::format?
use boost::format;
std::cout << format ("%first-name% %last-name%")
% format::arg("first-name", "Alan")
% format::arg("last-name", "Gutierrez")
<< std::endl;
It would not be terribly difficult to implement.
--
Alan Gutierrez - [EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
"William E. Kempf" <[EMAIL PROTECTED]> writes: > David Abrahams said: >> "William E. Kempf" <[EMAIL PROTECTED]> writes: >> int r = async_call(create_thread(), bind(g, 1, 2)); >> >> int r = async(boost::thread(), g, 1, 2); ^^^ >> >> int r = async_call(rpc(some_machine), bind(g,1,2)); >> >> int r = async_call(my_message_queue, bind(g,1,2)); >>> >>> None of these make much sense to me. You're executing the function >>> object in a supposedly asynchronous manner, but the immediate >>> assignment to int renders it a synchronous call. Am I missing >>> something again? >> >> No, my fault. Syntactically, I should've written this: >> >> async_call f(create_thread(), bind(g,1,2)); >> int r = f(); > > Do you want it to be "int r = f();" or just "int r = f;" or even "int r = > f.result();" or similar? My other message makes it clear (I hope) that I want what I wrote above. > The f() syntax makes it look like you're invoking the call at that > point, when in reality the call was invoked in the construction of > f. You're just invoking a function to get the result. f itself is not the result, so I don't want to use implicit conversion, and f.result() does not let f behave polymorphically in a functional programming context. >>> Ouch. A tad harsh. >> >> Sorry, not intended. I was just trying to palm off responsibility for >> justifying that line on you ;o) >> >>> But yes, I do see this concept applying to RPC invocation. "All" >>> that's required is the proxy that handles wiring the data and the >>> appropriate scaffolding to turn this into an Executor. Obviously this >>> is a much more strict implementation then thread >>> creation... you can't just call any function here. >> >> I don't get it. Could you fill in more detail? For example, where does >> the proxy come from? > >>From a lot of hard work? ;) Or often, it's generated by some IDL like > compiler. Traditional RPCs behave like synchronous calls, but DCOM and > other such higher level RPC mechanisms offer you alternative designs where > the initial invocation just wires the input to the server and you retreive > the results (which have been asynchronously wired back to the client and > buffered) at a later point. In my own work we often deal with RPC > mechanisms like this, that can take significant amounts of time to > generate and wire the results back, and the client doesn't need/want to > block waiting the whole time. Sure, sure, but all the details about the proxy, etc, are missing. Not that I think it matters... ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A new boost::thread implementation?
David Abrahams said: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >> David Abrahams said: >>> "William E. Kempf" <[EMAIL PROTECTED]> writes: >>> David Abrahams said: >>> ...and if it can't be default-constructed? >> >> That's what boost::optional<> is for ;). > > Yeeeh. Once the async_call returns, you have a value, and should be > able to count on it. You shouldn't get back an object whose > invariant allows there to be no value. I'm not sure I can interpret the "yeeeh" part. Do you think there's still an issue to discuss here? >>> >>> Yes. Yh means I'm uncomfortable with asking people to get >>> involved with complicated state like "it's there or it isn't there" >>> for something as conceptually simple as a result returned from >>> waiting on a thread function to finish. >> >> OK, *if* I'm totally understanding you now, I don't think the issue >> you see actually exists. The invariant of optional<> may allow >> there to be no value, but the invariant of a future/async_result >> doesn't allow this *after the invocation has completed*. (Actually, >> there is one case where this might occur, and that's when the >> invocation throws an exception if we add the async exception >> functionality that people want here. But in this case what happens is >> a call to res.get(), or what ever name we use, will throw an >> exception.) The optional<> is just an implementation detail that >> allows you to not have to use a type that's default constructable. > > It doesn't matter if the semantics of future ensures that the optional > is always filled in; returning an object whose class invariant is more > complicated than the actual intended result complicates life for the > user. The result of a future leaves it and propagates through other > parts of the program where the invariant established by future aren't as > obvious. Returning an optional where a double is intended is > akin to returning a vector that has only one element. Use the > optional internally to the future if that's what you need to do. The > user shouldn't have to mess with it. > >> If, on the other hand, you're concerned about the uninitialized state >> prior to invocation... we can't have our cake and eat it to, and since >> the value is meaningless prior to invocation any way, I'd rather allow >> the solution that doesn't require default constructable types. > > I don't care if you have an "uninitialized" optional internally to the > future. The point is to encapsulate that mess so the user doesn't have > to look at it, read its documentation, etc. I think there's some serious misunderstanding here. I never said the user would use optional<> directly, I said I'd use it in the implementation of this "async" concept. >> I *think* I understand what you're saying. So, the interface would be >> more something like: >> >> future f1 = thread_executor(foo, a, b, c); >> thread_pool pool; >> future f2 = thread_pool_executor(pool, foo, d, e, f); >> double d = f1.get() + f2.get(); >> >> This puts a lot more work on the creation of "executors" (they'll have >> to obey a more complex interface design than just "anything that can >> invoke a function object"), but I can see the merits. Is this >> actually what you had in mind? > > Something very much along those lines. I would very much prefer to > access the value of the future with its operator(), because we have lots > of nice mechanisms that work on function-like objects; to use get you'd > need to go through mem_fn/bind, and according to Peter we > wouldn't be able to directly get such a function object from a future > rvalue. Hmmm... OK, more pieces are falling into place. I think the f() syntax conveys something that's not the case, but I won't argue the utility of it. Only if you have a clearly defined "default case". Someone doing a lot of client/server development might argue with you about thread creation being a better default than RPC calling, or even thread_pool usage. >>> >>> Yes, they certainly might. Check out the systems that have been >>> implemented in Erlang with great success and get back to me ;-) >> >> Taking a chapter out of Alexander's book? > > Ooooh, touché! ;-) > > Actually I think it's only fair to answer speculation about what > people will like with a reference to real, successful systems. I'd agree with that, but the link you gave led me down a VERY long research path, and I'm in a time crunch right now ;). Maybe a short code example or a more specific link would have helped. >> As for the alternate interface your suggesting here, can you spell it >> out for me? > > I'm not yet wedded to a particular design choice, though I am getting > closer; I hope you don't think that's a cop-out. What I'm aiming for is > a particular set of design requirements: Not a cop-out, though I wasn't asking for a final design from you. > 1. Simple syntax, for some definition of "simple". > 2. A way
Re: [boost] Re: A new boost::thread implementation?
David Abrahams said: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > int r = async_call(create_thread(), bind(g, 1, 2)); > > int r = async(boost::thread(), g, 1, 2); >>>^^^ > > int r = async_call(rpc(some_machine), bind(g,1,2)); > > int r = async_call(my_message_queue, bind(g,1,2)); >> >> None of these make much sense to me. You're executing the function >> object in a supposedly asynchronous manner, but the immediate >> assignment to int renders it a synchronous call. Am I missing >> something again? > > No, my fault. Syntactically, I should've written this: > > async_call f(create_thread(), bind(g,1,2)); > int r = f(); Do you want it to be "int r = f();" or just "int r = f;" or even "int r = f.result();" or similar? The f() syntax makes it look like you're invoking the call at that point, when in reality the call was invoked in the construction of f. though. How do you envision this working? A local opaque function object can't be RPC'ed. >>> >>> It would have to not be opaque ;-) >>> >>> Maybe it's a wrapper over Python code that can be transmitted across >>> the wire. Anyway, I agree that it's not very likely. I just put it >>> in there to satisfy Bill, who seems to have some idea how RPC can be >>> squeezed into the same mold as thread invocation ;-) >> >> Ouch. A tad harsh. > > Sorry, not intended. I was just trying to palm off responsibility for > justifying that line on you ;o) > >> But yes, I do see this concept applying to RPC invocation. "All" >> that's required is the proxy that handles wiring the data and the >> appropriate scaffolding to turn this into an Executor. Obviously this >> is a much more strict implementation then thread >> creation... you can't just call any function here. > > I don't get it. Could you fill in more detail? For example, where does > the proxy come from? >From a lot of hard work? ;) Or often, it's generated by some IDL like compiler. Traditional RPCs behave like synchronous calls, but DCOM and other such higher level RPC mechanisms offer you alternative designs where the initial invocation just wires the input to the server and you retreive the results (which have been asynchronously wired back to the client and buffered) at a later point. In my own work we often deal with RPC mechanisms like this, that can take significant amounts of time to generate and wire the results back, and the client doesn't need/want to block waiting the whole time. -- William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] metrowerks linking errors
> It looks to me like the C library is not getting linked into the > executable. There are several possible versions of the C library which > might meet the need (some of them listed in the error messages). > Can you list the libraries that are being linked in? From that I can > probably make a better suggestion. No. I have no idea. This is bjam output. More examples you could see on win32 status page for Boost.Test unit tests. Maybe metrowerks toolset could answer your question. > -Howard Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] "unix" identification
> > a. _POSIX_C_SOURCE is not defined > > It's probably being overly picky requiring that one to be defined, strictly > speaking you can't use any POSIX API's unless _POSIX_C_SOURCE has been > defined before the inclusion of any std header - most platforms don't seem > to care though. > > > b. _POSIX_VERSION is smaller > > Particular platforms may have sigaction support even though they only claim > conformance to an earlier version of the POSIX standard - cygwin is one - > check for __CYGWIN__. So as a result we will get: #if defined(__CYGWIN__) || defined(_POSIX_VERSION) && (_POSIX_VERSION >= 199506L) Did I get it correct now? But look here what I dig up in status pages (not all compilers unfortunately provide config_info): A) gcc 3.1 on MacOS _POSIX_C_SOURCE is not defined _POSIX_VERSION=198808L _POSIX2_VERSION=199212L B) gcc 3.2 on HPUX _POSIX_C_SOURCE is not defined _POSIX_VERSION=199009L _POSIX2_VERSION=199209L C) gcc 3.2, gcc 2.95.3, intel 6.0, intel 7.0 kylix on linux _POSIX_C_SOURCE is defined _POSIX_VERSION=199506L _POSIX2_VERSION=199209L D) gcc 2.95.3, gcc 3.2 on OpenBSD _POSIX_C_SOURCE is not defined _POSIX_VERSION=199009L _POSIX2_VERSION=199212L Cases A,B and D will be ruled out. Any suggestions? Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [test] metrowerks linking errors
On Sunday, February 9, 2003, at 03:30 AM, Gennadiy Rozental wrote:
Hi,
Could somebody shed some light on what may be the cause of the
following
link errors issued by metrowerks compiler in Boost.Test unit tests:
### mwld Linker Error:
# Undefined symbol: '__declspec(dllimport) _getenv (__imp__getenv)'
# referenced from '_main' in cpp_main.cpp:61
(libboost_prg_exec_monitor.lib)
# referenced from '_main' in cpp_main.cpp:71
(libboost_prg_exec_monitor.lib)
### mwld Linker Error:
# Note: symbol '_getenv' found in 'MSL_C_x86.lib';
# your project may need MSL_All-DLL_{x86,3DNow,MSE}[_D].lib instead
### mwld Linker Error:
# Undefined symbol: '__declspec(dllimport) _strcmp (__imp__strcmp)'
# referenced from '_main' in cpp_main.cpp:62
(libboost_prg_exec_monitor.lib)
# referenced from '_main' in cpp_main.cpp:72
(libboost_prg_exec_monitor.lib)
### mwld Linker Error:
# Note: symbol '_strcmp' found in 'MSL_C_x86.lib';
# your project may need MSL_All-DLL_{x86,3DNow,MSE}[_D].lib instead
It looks to me like the C library is not getting linked into the
executable. There are several possible versions of the C library which
might meet the need (some of them listed in the error messages).
Can you list the libraries that are being linked in? From that I can
probably make a better suggestion.
-Howard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] date_time release mode errors
> execute-test > ..\status\bin\testdate_iterator.test\vc7\release\runtime-link-dynamic\testda > te_iterator.run > == BEGIN OUTPUT == > Pass :: base iterator > 20020101 20020102 20020103 20020203 > Pass :: day iterator -- 2 days > Pass :: day iterator -- 2 days > Pass :: day iterator -- 2 days > FAIL :: day iterator -- 2 days >...more cut... In case it is obvious the iterator isn't terminating properly. There are only supposed to be 3 iterations which means that either the itr++ isn't working correctly of the date comparison isn't working correctly. There are other date comparison tests in testdate.cpp so my guess would be that itr++ has gone bad for some reason. ..\status\bin\testfacet.test\vc7\release\runtime-link-dynamic\testfacet.exe > testfacet.obj : error LNK2019: unresolved external symbol "public: char > const * __thiscall boost::gregorian::greg_month::as_short_string(void)const > " (?as_short_string@greg_month@gregorian@boost@@QBEPBDXZ) referenced in > function "protected: virtual void __thiscall > boost::date_time::date_names_put boost::gregorian::greg_facet_config,char,class > std::ostreambuf_iterator > > >::do_put_month_short(class std::ostreambuf_iterator std::char_traits > &,enum boost::gregorian::months_of_year)const " > (?do_put_month_short@?$date_names_put@Ugreg_facet_config@gregorian@boost@@DV > ?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@date_time@boost@@MBEXAAV > ?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@W4months_of_year@gregoria > n@3@@Z) > testfacet.obj : error LNK2019: unresolved external symbol "public: char > const * __thiscall boost::gregorian::greg_month::as_long_string(void)const " > (?as_long_string@greg_month@gregorian@boost@@QBEPBDXZ) referenced in > function "protected: virtual void __thiscall > boost::date_time::date_names_put boost::gregorian::greg_facet_config,char,class > std::ostreambuf_iterator > > >::do_put_month_long(class std::ostreambuf_iterator std::char_traits > &,enum boost::gregorian::months_of_year)const " > (?do_put_month_long@?$date_names_put@Ugreg_facet_config@gregorian@boost@@DV? > $ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@date_time@boost@@MBEXAAV? > $ostreambuf_iterator@DU?$char_traits@D@std@@@std@@W4months_of_year@gregorian > @3@@Z) > ..\status\bin\testfacet.test\vc7\release\runtime-link-dynamic\testfacet.exe > : fatal error LNK1120: 2 unresolved externals This (and all the rest of the failures) are an indication that the library hasn't been built correctly or isn't being linked because it is complaining about symbols built into libboost_date_time. HTH, Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time release mode errors
Building the date_time regression tests with VC7 in release mode causes a number of failures to show up that don't appear in debug mode, anyone any ideas? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ...found 939 targets... ...updating 38 targets... execute-test ..\status\bin\testdate_iterator.test\vc7\release\runtime-link-dynamic\testda te_iterator.run == BEGIN OUTPUT == Pass :: base iterator 20020101 20020102 20020103 20020203 Pass :: day iterator -- 2 days Pass :: day iterator -- 2 days Pass :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days Pass :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days Pass :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 days FAIL :: day iterator -- 2 day
Re: [boost] [test] "unix" identification
> > How about: > > > > #if defined(_POSIX_C_SOURCE) && defined(_POSIX_VERSION) && > > (_POSIX_VERSION >= 199506L) && !defined(_WIN32) > > > > which should be about right if I've understood the standard correctly. > > IMO there are several issues with above check. If you would take a look here > http://boost.sourceforge.net/regression-logs/cs-win32-links.html#config_info > %20gcc > > you will see that > > a. _POSIX_C_SOURCE is not defined It's probably being overly picky requiring that one to be defined, strictly speaking you can't use any POSIX API's unless _POSIX_C_SOURCE has been defined before the inclusion of any std header - most platforms don't seem to care though. > b. _POSIX_VERSION is smaller Particular platforms may have sigaction support even though they only claim conformance to an earlier version of the POSIX standard - cygwin is one - check for __CYGWIN__. > P.S. Also let me revisit my other related question: would it be ok on all > compatible platforms to use csignal instead of signal.h? No, sigaction and friends aren't part of the C++ or C standards: you need to include to get the full unix definitions, not just those required by C++. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] metrowerks linking errors
Hi,
Could somebody shed some light on what may be the cause of the following
link errors issued by metrowerks compiler in Boost.Test unit tests:
### mwld Linker Error:
# Undefined symbol: '__declspec(dllimport) _getenv (__imp__getenv)'
# referenced from '_main' in cpp_main.cpp:61
(libboost_prg_exec_monitor.lib)
# referenced from '_main' in cpp_main.cpp:71
(libboost_prg_exec_monitor.lib)
### mwld Linker Error:
# Note: symbol '_getenv' found in 'MSL_C_x86.lib';
# your project may need MSL_All-DLL_{x86,3DNow,MSE}[_D].lib instead
### mwld Linker Error:
# Undefined symbol: '__declspec(dllimport) _strcmp (__imp__strcmp)'
# referenced from '_main' in cpp_main.cpp:62
(libboost_prg_exec_monitor.lib)
# referenced from '_main' in cpp_main.cpp:72
(libboost_prg_exec_monitor.lib)
### mwld Linker Error:
# Note: symbol '_strcmp' found in 'MSL_C_x86.lib';
# your project may need MSL_All-DLL_{x86,3DNow,MSE}[_D].lib instead
Thank you,
Gennadiy
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] "unix" identification
Hi, Some time ago there was a discussion on how properly identify "unix" for selecting proper signal handling algorithm. Here is fragment of John Maddok's letter: > ... currently you have: > > // for testing on Win32, GCC thinks it is a unix platform > // TODO: figure out how to tell it is really unix > #elif defined(__unix) && !defined(__GNUC__) > > There are several things wrong with this: > > __unix need not be defined on POSIX conforming systems > __unix may be defined on systems that don't support sigaction etc. > almost all version of __GNUC__ do have sigaction support including > cygwin. > > How about: > > #if defined(_POSIX_C_SOURCE) && defined(_POSIX_VERSION) && > (_POSIX_VERSION >= 199506L) && !defined(_WIN32) > > which should be about right if I've understood the standard correctly. IMO there are several issues with above check. If you would take a look here http://boost.sourceforge.net/regression-logs/cs-win32-links.html#config_info %20gcc you will see that a. _POSIX_C_SOURCE is not defined b. _POSIX_VERSION is smaller Nevertheless, I was able to check that this version of gcc perfectly compile and work with unix style signal handling. Accordingly here is the question: how properly identify the "unix" style signal handling? Gennadiy. P.S. Also let me revisit my other related question: would it be ok on all compatible platforms to use csignal instead of signal.h? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
