[safebool] Can we generalize it and put it into utilities?
Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities? struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result; explicit safebool(bool v) : value_(v) {} operator result() const { return value_ ? &safebool::internal_bool : 0; } private: void internal_bool() const {}; bool value_; }; That way all we (and the users) will have to do to deploy the technique will be class Foo { ... operator safebool::result() const { return safebool(my_condition); } }; This seems simple and hassle-free. Thanks, Vladimir.
Hi, ----- Original Message ----- From: <Vladimir.Batov@wrsa.com.au> To: <boost@lists.boost.org> Cc: <Vladimir.Batov@wrsa.com.au> Sent: Sunday, March 29, 2009 11:18 PM Subject: [boost] [safebool] Can we generalize it and put it into utilities?
Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities?
struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result;
explicit safebool(bool v) : value_(v) {}
operator result() const { return value_ ? &safebool::internal_bool : 0; }
private:
void internal_bool() const {};
bool value_; };
That way all we (and the users) will have to do to deploy the technique will be
class Foo { ... operator safebool::result() const { return safebool(my_condition); } };
This seems simple and hassle-free.
Yes, this seems much more simple and open than the mixin approach. Why do you use result instead of unspecified_bool_type. The following it enough clear to me class Foo { ... operator safebool::unspecified_bool_type() const { return safebool(my_condition); } }; I like it anyway, Vicente
vicente.botet <vicente.botet <at> wanadoo.fr> writes: ... Yes, this seems much more simple and open than the mixin approach. Why do you use result instead of unspecified_bool_type. The following it enough clear to me
class Foo { ... operator safebool::unspecified_bool_type() const { return safebool(my_condition); } };
For users' sake I'd like to stay within the mainstream vocabulary. Like type, value, result, etc. Indeed, for an initiated person the "unspecified_bool_type" looks familiar. However, I still remember the what-the... feeling when I came across it first time.
I like it anyway, Vicente
Glad to hear I am not alone. Best, V.
AMDG Vladimir Batov wrote:
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
class Foo { ... operator safebool::unspecified_bool_type() const { return safebool(my_condition); } };
For users' sake I'd like to stay within the mainstream vocabulary. Like type, value, result, etc. Indeed, for an initiated person the "unspecified_bool_type" looks familiar. However, I still remember the what-the... feeling when I came across it first time.
I like it anyway,
Glad to hear I am not alone.
I've written this far too many times, so I also would appreciate a common solution. I think it would be more straightforward to use a namespace scope typedef and a free function rather than a class, though. typedef ... safe_bool; safe_bool make_safe_bool(bool); In Christ, Steven Watanabe
AMDG Vladimir.Batov@wrsa.com.au wrote:
Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities?
struct safebool { typedef void (safebool::*unspecified_bool_type)() const; typedef unspecified_bool_type result;
explicit safebool(bool v) : value_(v) {}
operator result() const { return value_ ? &safebool::internal_bool : 0; }
private:
void internal_bool() const {};
bool value_; };
That way all we (and the users) will have to do to deploy the technique will be
class Foo { ... operator safebool::result() const { return safebool(my_condition); } };
This seems simple and hassle-free.
I just noticed this in boost/detail/identifier.hpp typedef void (*unspecified_bool_type)(D); // without the D, unspecified_bool_type static void unspecified_bool_true(D){} // conversion allows relational operators // between different identifier types So, here's another take on it: template<class Tag> struct safe_bool { typedef void (safe_bool::*result_type)(); result_type operator()(bool b) { return b? &safe_bool::true_ : 0 } private: void true_() {} }; In Christ, Steven Watanabe
From: "Steven Watanabe" <watanabesj@gmail.com> So, here's another take on it:
template<class Tag> struct safe_bool { typedef void (safe_bool::*result_type)(); result_type operator()(bool b) { return b? &safe_bool::true_ : 0 } private: void true_() {} };
Yes, "templatazing" makes sense. The deployment will probably be as follows: class Foo { ... operator safe_bool<Foo>::result_type() const { return safe_bool<Foo>()(my_condition); } }; Is it considerably different from what I suggested initially? That is, class Foo { ... operator safebool<Foo>::result() const { return safebool<Foo>(my_condition); } }; I do understand that my suggested variant stores the condition internally. I did it for the sake of simplifying the user interface as I find the usage immediately above fairly conventional. Does that variable adds too much overhead? A way to avoid it certainly would be via a function similar to: operator safebool<Foo>::result() const { return safebool<Foo>::apply(my_condition); } operator safebool<Foo>::result() const { return safebool<Foo>()(my_condition); } Best, V.
On Monday, March 30, 2009 7:34 AM Vladimir Batov wrote:
From: "Steven Watanabe" <watanabesj@gmail.com> So, here's another take on it:
template<class Tag> struct safe_bool { typedef void (safe_bool::*result_type)(); result_type operator()(bool b) { return b? &safe_bool::true_ : 0 } private: void true_() {} };
Yes, "templatazing" makes sense. The deployment will probably
It isn't immediately obvious why it is sensible, so that must be documented.
be as follows:
class Foo { ... operator safe_bool<Foo>::result_type() const { return safe_bool<Foo>()(my_condition); } };
The extra parentheses to invoke the function call operator will trip up many would-be users, so a named function would be better. A function template can make this even easier: template <class Tag> inline safe_bool<Tag>::result_type make_safe_bool(bool _value) { return safe_bool<Tag>::apply(_value); } Usage is now: class Foo { ... operator safe_bool<Foo>::result_type() const { return make_safe_bool<Foo>(condition_); } }; _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Based on the suggestions from Steven Watanabe and Robert Stewart I've uploaded safebool.hpp into the Vault. It can be deployed as struct Foo { ... operator safebool<Foo>::type() const { return safebool<Foo>(condition); } }; or operator safebool<Foo>::type() const { return safebool<Foo>::make(c); } or operator safebool<Foo>::type() const { return make_safebool<Foo>(c); } I still like the first one but the other two seemed strong contenders and I realize they might be marginally faster (in theory anyway). Documented the need, the usage and the solution. Best, V.
On Monday, March 30, 2009 7:09 PM Vladimir Batov wrote:
struct Foo { ... operator safebool<Foo>::type() const { return safebool<Foo>(condition); } };
I think "safe_bool" is the better spelling than "safebool" because "safe" and "bool" are separate words. "type" is a good replacement for "result" since it is shorter, but don't call the member function pointer. That is, omit the parentheses: operator safe_bool<Foo>::type { return safe_bool<Foo>(condition); } I don't care for the implicit conversion on which that relies.
or operator safebool<Foo>::type() const { return safebool<Foo>::make(c); }
"make" should be spelled "apply." It's longer but more in keeping with the rest of Boost.
or operator safebool<Foo>::type() const { return make_safebool<Foo>(c); }
I still like the first one but the other two seemed strong contenders and I realize they might be marginally faster (in theory anyway).
There's certainly something to be said for avoiding the construction of a temporary in which to save the bool on which the implicit conversion operator depends. Everything is simpler: template <class T> struct safe_bool { typedef void (safe_bool::*type)() const; static type apply(bool _value) { return _value ? &safe_bool::_() : 0; } void _() const {}; }; I took the liberty of renaming "true_" to "_" as the function exists only as a placeholder and shouldn't be used. You can make it private if you like, of course, but who would bother creating an instance of safe_bool<T> just to call the _ member function that does nothing? make_safe_bool<Foo>(c) would be easier written make_safe_bool(this, c), with the compiler deducing Foo from this, but since the return type must already be spelled safe_bool<Foo>::type, then the function body can be spelled safe_bool<Foo>::apply(c) just as easily. Usage is now: struct Foo { ... operator safe_bool<Foo>::type() const { return safe_bool<Foo>::apply(condition); } ... }; That looks clean and consistent.
Documented the need, the usage and the solution.
The rationale for templatizing the code is good. I'm glad you included that. It might be good to link to http://www.artima.com/cppsource/safebool.html, Bjorn Karlsson's article on the subject, for background. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
I think "safe_bool" is the better spelling than "safebool" because "safe" and "bool" are separate words.
Understood. Although there are plenty of examples of new words made up of other words: widespread, wholesale, cellphone, ... long list. This situation looks similar to those many re-create vs. recreate, etc. Both are quite acceptable (I think). I am on the fence with regard to safebool vs. safe_bool with a slight tilt towards safebool. Steven favored safe_bool as well. Let's see if others step forward liking safebool. If not, well, I'll change. :-)
... don't call the member function pointer. That is, omit the parentheses:
operator safe_bool<Foo>::type { return safe_bool<Foo>(condition); }
I do not understand how the above (with parentheses omitted) can possibly work. The original does not call the member function pointer. It is an implicit conversion to that type. Same as operator safebool<Foo>::type() const { return safebool<Foo>::apply(c); } I probably do not understand what you mean.
"make" should be spelled "apply." It's longer but more in keeping with the rest of Boost.
OK. Changed.
There's certainly something to be said for avoiding the construction of a temporary in which to save the bool on which the implicit conversion operator depends. Everything is simpler:
Yes, simpler... as far as the implementation goes. I do not believe it is as applicable to the interface (which has the preference): operator safebool<Foo>::type() const { return safebool<Foo>(c); } operator safebool<Foo>::type() const { return safebool<Foo>::apply(c); } To me (the user) #1 is shorter, looks simpler, reads more naturally and one less word to remember. With *both* interfaces supported I am not sure it is worth fighting for one or the other. Maybe, instead, we might dump one of the following: operator safebool<Foo>::type() const { return safebool<Foo>::apply(c); } operator safebool<Foo>::type() const { return make_safebool<Foo>(c); } Or we might keep both though.
... make_safe_bool<Foo>(c) would be easier written make_safe_bool(this, c), with the compiler deducing Foo from this, but since the return type must already be spelled safe_bool<Foo>::type, then the function body can be spelled safe_bool<Foo>::apply(c) just as easily.
Yes, I prefer spelling safebool<> for consistency.
Usage is now:
struct Foo { ... operator safe_bool<Foo>::type() const { return safe_bool<Foo>::apply(condition); } ... };
That looks clean and consistent.
Apart from safebool vs. safe_bool we've got just that.
... It might be good to link to http://www.artima.com/cppsource/safebool.html, Bjorn Karlsson's article on the subject, for background.
Added. V.
On Monday, March 30, 2009 9:53 PM Vladimir Batov wrote:
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
I think "safe_bool" is the better spelling than "safebool" because "safe" and "bool" are separate words.
Understood. Although there are plenty of examples of new words made up of other words: widespread, wholesale, cellphone, ... long list.
Your examples from English are valid (though my spelling checker wants to change "cellphone" to "cell phone" ;-). However, if you compare Google results for "safe bool" with those for "safebool," subtracting noise from the latter, like hits on "safe bool," this Boost discussion, and "SafeBool," you'll see a distinct preference for "safe bool." IOW, most usage modifies "bool" with the adjective "safe" rather than forming a new type named "safebool."
... don't call the member function pointer. That is, omit the parentheses:
operator safe_bool<Foo>::type { return safe_bool<Foo>(condition); }
I do not understand how the above (with parentheses omitted) can possibly work. The original does not call the member function pointer. It is an implicit conversion to that type.
I kept seeing a return type and not a conversion operator. I was looking past "operator" and manufactured a function name, apparently! I was tired and unwell. I'm sorry to confuse you.
There's certainly something to be said for avoiding the construction of a temporary in which to save the bool on which the implicit conversion operator depends. Everything is simpler:
Yes, simpler... as far as the implementation goes. I do not believe it is as applicable to the interface (which has the preference):
Neither is complicated, I'll grant. I just figured the class would be easier to understand in its simpler form and the usage is but slightly altered.
operator safebool<Foo>::type() const { return safebool<Foo>(c); }
operator safebool<Foo>::type() const { return safebool<Foo>::apply(c); }
To me (the user) #1 is shorter, looks simpler, reads more naturally and one less word to remember.
The former relies on creating a temporary and accessing a nested type, thus there's a slight inconsistency in using "safe_bool<Foo>." The latter involves a static member function, rather than an instance, and the nested type, so "safe_bool<Foo>::" is used for both. There's also no conversion operator to invoke. It's just a more straightforward mechanism with more consistency between the return type and invocation, together making it slightly nicer.
With *both* interfaces supported I am not sure it is worth fighting for one or the other. Maybe, instead, we might dump one of the following:
I agree with Steven. One interface is sufficient. It would be nice to have more opinions, however. I expect this will warrant a fast-track review, but you could hope for more opinions at that time, since few are available now.
make_safe_bool<Foo>(c) would be easier written make_safe_bool(this, c), with the compiler deducing Foo from this, but since the return type must already be spelled safe_bool<Foo>::type, then the function body can be spelled safe_bool<Foo>::apply(c) just as easily.
Yes, I prefer spelling safebool<> for consistency.
From that response, I'm unsure whether you took my point. To be clear, given the choices,
1) safe_bool<Foo>::apply(c) and 2) make_safe_bool(this, c), and the conversion type, safe_bool<Foo>::type, 1) is more consistent than 2), so we should eliminate 2). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
Your examples from English are valid (though my spelling checker wants to change "cellphone" to "cell phone" .
Yes, 'dictionary.com' insists on them being separate... but, in fact, that was in part my point -- language is a living thing, words get together, move in and out. Some compound words which used to properly written with a dash (like multi-storey) are losing dashes. Some never even had the dashes (like 'file name') but still got together anyway. For many something like file_name will not probably look right. That said, I renamed safebool to safe_bool :-) so that we could pass that point.
...
{ return safebool<Foo>(c); } { return safebool<Foo>::apply(c); }
The former relies on creating a temporary and accessing a nested type, ... The latter involves a static member function, ... It's just a more straightforward mechanism with more consistency between the return type and invocation, together making it slightly nicer.
I actually agree with you... but that's implementation detail that the user does not care or deal with. As for the interface due to utter simplicity of that safe_bool I'd like it to be deployable with as little effort as possible. Therefore, I feel from the *user* point of view the former wins over the latter.
I agree with Steven. One interface is sufficient. It would be nice to have more opinions, however.
For the time being I'll keep both (as above).
I expect this will warrant a fast-track review, but you could hope for more opinions at that time, since few are available now.
Yes, I prefer spelling safebool<> for consistency.
From that response, I'm unsure whether you took my point. To be clear, given
Yes, a fast-track review makes sense and would be nice... or just a review. :-) You might have noticed I was not exactly lucky getting to the review phase. :-) I am probably missing some important process steps (although I did read the relevant pages). If you could give me a hand with that, it'd be much appreciated and I'd know how to do it properly without irking people. the choices,
1) safe_bool<Foo>::apply(c) and 2) make_safe_bool(this, c),
and the conversion type,
safe_bool<Foo>::type,
1) is more consistent than 2), so we should eliminate 2).
Sorry for being unclear. Yes, I like and implemented #1. The 'make_...' has been removed altogether. Best, V.
On Tuesday, March 31, 2009 6:07 PM Vladimir Batov wrote:
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
{ return safebool<Foo>(c); } { return safebool<Foo>::apply(c); }
The former relies on creating a temporary and accessing a nested type, ... The latter involves a static member function, ... It's just a more straightforward mechanism with more consistency between the return type and invocation, together making it slightly nicer.
I actually agree with you... but that's implementation detail that the user does not care or deal with. As for the interface due to utter simplicity of that safe_bool I'd like it to be deployable with as little effort as possible. Therefore, I feel from the *user* point of view the former wins over the latter.
That was the point of view from which I was looking, too. I think the following is the easier usage because of the consistency (highlighted, to be sure, by the formatting used here): struct Foo { operator safe_bool<Foo>::type() { return safe_bool<Foo>::apply(condition); } }; This is a valid case to reserve until review in the hopes of getting additional opinions. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
AMDG Vladimir Batov wrote:
Based on the suggestions from Steven Watanabe and Robert Stewart I've uploaded safebool.hpp into the Vault. It can be deployed as
struct Foo { ... operator safebool<Foo>::type() const { return safebool<Foo>(condition); } }; or operator safebool<Foo>::type() const { return safebool<Foo>::make(c); } or operator safebool<Foo>::type() const { return make_safebool<Foo>(c); }
I still like the first one but the other two seemed strong contenders and I realize they might be marginally faster (in theory anyway).
I consider any speed differences to be highly unlikely. IMO, you should pick one interface and stick to it. There is no reason to provide several ways to do the same thing when there are only minor syntactic differences.
Documented the need, the usage and the solution.
In Christ, Steven Watanabe
From: "Steven Watanabe" <watanabesj@gmail.com> I consider any speed differences to be highly unlikely. IMO, you should pick one interface and stick to it. There is no reason to provide several ways to do the same thing when there are only minor syntactic differences.
Thanks, Steven. This is much appreciated. In my own work I certainly strive to provide one way to do one thing. Here with so many different opinions, preferences, etc. I find it difficult. If we are to pick one out of the following three: { return safebool<Foo>(c); } { return safebool<Foo>::apply(c); } { return make_safebool<Foo>(c); } Then, I can't think of a reason why the user might prefer 'safebool::apply()' to just 'safebool()'. As for or 'make_safebool', then make_pair() was introduced to simplify pair creation. Given creating safebool is straightforward, I do not feel 'make_safebool' makes things any clearer. V.
Vladimir.Batov wrote:
Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities?
[snip]
Given a large number of known problems [1] and the forthcoming addition of explicit conversion operators to c++, it might be better to provide a macro. [1] http://svn.boost.org/svn/boost/trunk/boost/smart_ptr/detail/operator_bool.hp...
Ilya Sokolov <ilyasokol <at> gmail.com> writes:
Given a large number of known problems [1] and the forthcoming addition of explicit conversion operators to c++, it might be better to provide a macro.
[1] http://svn.boost.org/svn/boost/trunk/boost/smart_ptr/detail/operator_bool.hp...
Ilya, thank you for chiming in. Much appreciated. I am not exactly sure I understand. What are the "large number of known problems"? Your reference of operator_bool.hpp does not strike me as such. Do you have anything in mind that was not mentioned in the chapter 7.7 of Alexandrescu's "Modern C++ Design" or/and the article at http://www.artima.com/cppsource/safe_bool.html by Bjorn Karlsson? I glanced over "explicit conversion operators" in C++0x. It did not struck me as relevant to safe_bool. Care to elaborate? Best, V.
Hi, On Wed, Apr 1, 2009 at 6:20 AM, Vladimir Batov <vladimir.batov@wrsa.com.au>wrote:
I glanced over "explicit conversion operators" in C++0x. It did not struck me as relevant to safe_bool. Care to elaborate?
It is relevant since you can say, define an explicit conversion function to convert to bool, and yet avoid the very problems with say, also allowing implicit conversion to int, that the safe bool idiom is used to avoid. In other words, it is a language feature directly designed to replace the safe bool idiom, and more. Regards, Eugene Wee
Eugene Wee <crystalrecursion <at> gmail.com> writes:
I glanced over "explicit conversion operators" in C++0x. It did not struck me as relevant to safe_bool. Care to elaborate?
It is relevant since you can say, define an explicit conversion function to convert to bool, and yet avoid the very problems with say, also allowing implicit conversion to int, that the safe bool idiom is used to avoid. In other words, it is a language feature directly designed to replace the safe bool idiom, and more.
Ah, my bad, I was damn looking at something completely else. :-( Now I found the relevant section (12.3.2. Conversion functions) and see that adding 'explicit' seem to fix all the problems we are now trying to solve with safe_bool. Thanks for setting me straight. Problem solved then... well, it is being taken care of, anyway. Sorry for all the noise. Thanks, V.
On Tuesday, March 31, 2009 5:06 PM Ilya Sokolov wrote:
Vladimir.Batov wrote:
Repeating safe-bool scaffolding over and over again is a real nuisance. It is worse for the end users as not exactly everyone is intimately familiar with the issue and the safe-bool workaround. Can we generalize it and put something like the following into utilities?
Given a large number of known problems [1] and the forthcoming addition of explicit conversion operators to c++, it might be better to provide a macro.
[1] http://svn.boost.org/svn/boost/trunk/boost/smart_ptr/detail/operator_bool.hp...
There are definitely portability workarounds necessary for shared_ptr, based upon Peter's work in that library. If any of those actually apply to safe_bool, they can be captured in the safe_bool class Vladimir has implemented. Of course, some of the older compilers can be ignored by this new utility. To account for the need for operator bool() in the SunPro case, a macro would certainly be needed. However, such an operator is hardly a safe bool, so that case might simply be ignored. If support for that is included, I suggest that the macro be introduced as a means to extend support to older compilers so that those not needing such support can forego the macro. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (8)
-
Eugene Wee -
Ilya Sokolov -
Steven Watanabe -
Stewart, Robert -
vicente.botet -
Vladimir Batov -
Vladimir Batov -
Vladimir.Batov＠wrsa.com.au