[convert] Now with Boost.Parameter interface.

[Vladimir Batov-2]

I've incorporated, uploaded to the Vault and started playing with the
Boost.Parameter-based interface that Andrey Semashev was insisting from
the set-go. And it is definitely growing on me and I like

        int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
true);

instead of the original

        int i = convert<int>::from(str, 0) >> new_locale >> dothrow;

I think people generally did not like locales and dothrow behaving like
manipulators.

The more I use the Boost.Parameter-based interface the more I am inclined
to push it further and apply it to manipulators as well. I.e.

        int i = convert<int>::from(str)(radix_ = 16);

instead of the original direct handling of std manipulators.

        int i = convert<int>::from(str) >> std::hex;

Something, again, Andrey was advocating from the start. Now it feels like
allowing io-stream manipulators exposes too much implementation detail and
raises some unwarranted expectations.

That raises a few questions that I am hoping people could help me with:

1. Both interfaces (for locale and dothrow) are currently supported:

#1        int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_
= true);
#2        int i = convert<int>::from(str, 0) >> new_locale >> dothrow;

Should I remove #1?

2. Both interfaces

#1        int i = convert<int>::from(str, 0) >> std::hex;
#2        int i = convert<int>::from(str, 0)(radix_ = 16);

are currently supported. Should I move away from direct manipulator
support and remove #1?

3. I only managed to figure out how to supply only one Boost.Parameter at
a time like

        int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
true);

I understand how to achieve

        int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ =
true));

(with double quotes) but do not want to go there as it looks somewhat
unorthodox. I cannot figure out how to achieve the following

        int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ =
true);

(a list inside single quotes). I remember Andrey mentioning I could do
that with a Boost.Parameter macro but I admit of not being bright enough
to figure it out by myself. Any help would be greatly appreciated.

Thanks,
Vladimir.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Batov-2]

Should have proof-read before posting. Apologies.

> Vladimir.Batov <at> wrsa.com.au> writes:
> 1. Both interfaces (for locale and dothrow) are currently supported:
>
> #1 int i=convert<int>::from(str, 0)(locale_=new_locale)(throw_=true);
> #2 int i=convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> Should I remove #1?

Meant to say "Should I remove #2?"

> I understand how to achieve
>
> int i=convert<int>::from(str, 0)((locale_=new_locale, throw_=true));
>
> (with double quotes) ...
> (a list inside single quotes).

Certainly meant double *brackets*. Apologies.

Thanks,
Vladimir.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Max-156]

Hello list,

I'm migrating from 1.38 to 1.39. When building my program,
I got an link error like this:

LINK : fatal error LNK1104: cannot open file
'libboost_thread-vc90-mt-1_38.lib'

I've set the correct include path and lib path for the IDE. And I've
confirmed that

- there's no items in the "Additional Dependendies" in the Liker section of
the
project properties dialog.
- I've not introduced lib dependendies via #pragma lib directives.

And it's a small program, mainly depends on boost and CGAL.

I have also rebuilt all of the CGAL lib's with boost 1.39.0.

I just cannot how the program depends, directly or indirectly, on
libboost_thread-vc90-mt-1_38.lib.

I'm using MS VS2008SP1 in Windows XP/SP1.

I think ithis problem is of a general value, even though it doesn't have
that much
to do with boost itself. And I believe the boost guys will have an idea.

Thanks for any information.

B/Rgds
Max

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Marcus Lindblom]

Max wrote:
> Hello list,
>
> I'm migrating from 1.38 to 1.39. When building my program,
> I got an link error like this:
>
> LINK : fatal error LNK1104: cannot open file
> 'libboost_thread-vc90-mt-1_38.lib'

[snip]

> I just cannot how the program depends, directly or indirectly, on
> libboost_thread-vc90-mt-1_38.lib.

Try searching your object files for that string, it might help to track
down where the auto-include statement originates.

Cheers,
/Marcus
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus-3]

Max wrote:

> Hello list,

Please do not ask questions by replying to an unrelated email.

> I'm migrating from 1.38 to 1.39. When building my program,
> I got an link error like this:
>
> LINK : fatal error LNK1104: cannot open file
> 'libboost_thread-vc90-mt-1_38.lib'

Your program appears to auto-link to 1.38.

> I've set the correct include path and lib path for the IDE. And I've
> confirmed that
>
> - there's no items in the "Additional Dependendies" in the Liker section of
> the
> project properties dialog.
> - I've not introduced lib dependendies via #pragma lib directives.
>
> And it's a small program, mainly depends on boost and CGAL.
>
> I have also rebuilt all of the CGAL lib's with boost 1.39.0.
>
> I just cannot how the program depends, directly or indirectly, on
> libboost_thread-vc90-mt-1_38.lib.

Have you cleaned every single object files that compise your application.
Are you sure you don't have include paths still pointing at 1.38?

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Max-156]

>
> Please do not ask questions by replying to an unrelated email.

That's terrible! How do you know I was asking questions by replying
to an unrelated email? Yes. I was replying an unrelated email as a basis,
but I believe I have changed all of the unrelated information to those
related.

How do you do that? :-)

>
> > I'm migrating from 1.38 to 1.39. When building my program,
> > I got an link error like this:
> >
> > LINK : fatal error LNK1104: cannot open file
> > 'libboost_thread-vc90-mt-1_38.lib'
>
> Your program appears to auto-link to 1.38.
>
> > I've set the correct include path and lib path for the IDE. And I've
> > confirmed that
> >
> > - there's no items in the "Additional Dependendies" in the Liker section

of

> > the
> > project properties dialog.
> > - I've not introduced lib dependendies via #pragma lib directives.
> >
> > And it's a small program, mainly depends on boost and CGAL.
> >
> > I have also rebuilt all of the CGAL lib's with boost 1.39.0.
> >
> > I just cannot how the program depends, directly or indirectly, on
> > libboost_thread-vc90-mt-1_38.lib.
>
> Have you cleaned every single object files that compise your application.
> Are you sure you don't have include paths still pointing at 1.38?

Yes, I've also double checked this aspect.

>
> - Volodya
>

Thanks for your reply.

B/Rgds
Max

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Prus-3]

Max wrote:

>>
>> Please do not ask questions by replying to an unrelated email.
>
> That's terrible! How do you know I was asking questions by replying
> to an unrelated email? Yes. I was replying an unrelated email as a basis,
> but I believe I have changed all of the unrelated information to those
> related.
>
> How do you do that? :-)

If that's an non-rhetoric question, take a look at

        http://thread.gmane.org/gmane.comp.lib.boost.devel/189020

which clearly shows your email inside unrelated thread. The "reply-to"
command in all decent software sets In-Reply-To header, and most clients
use that to display threads, therefore replying to unrelated email make
your message appear where it might be missed, or interfere with other
discussion.

>> > I'm migrating from 1.38 to 1.39. When building my program,
>> > I got an link error like this:
>> >
>> > LINK : fatal error LNK1104: cannot open file
>> > 'libboost_thread-vc90-mt-1_38.lib'
>>
>> Your program appears to auto-link to 1.38.
>>
>> > I've set the correct include path and lib path for the IDE. And I've
>> > confirmed that
>> >
>> > - there's no items in the "Additional Dependendies" in the Liker section
> of
>> > the
>> > project properties dialog.
>> > - I've not introduced lib dependendies via #pragma lib directives.
>> >
>> > And it's a small program, mainly depends on boost and CGAL.
>> >
>> > I have also rebuilt all of the CGAL lib's with boost 1.39.0.
>> >
>> > I just cannot how the program depends, directly or indirectly, on
>> > libboost_thread-vc90-mt-1_38.lib.
>>
>> Have you cleaned every single object files that compise your application.
>> Are you sure you don't have include paths still pointing at 1.38?
>
> Yes, I've also double checked this aspect.

Then, I guess you get to do what Marcus Lindblom suggested -- finding
which object file grabs that library.

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Max-156]

> >> Please do not ask questions by replying to an unrelated email.
> >
> > That's terrible! How do you know I was asking questions by replying
> > to an unrelated email? Yes. I was replying an unrelated email as a
basis,

> > but I believe I have changed all of the unrelated information to those
> > related.
> >
> > How do you do that? :-)
>
> If that's an non-rhetoric question, take a look at
>
>         http://thread.gmane.org/gmane.comp.lib.boost.devel/189020
>
> which clearly shows your email inside unrelated thread. The "reply-to"
> command in all decent software sets In-Reply-To header, and most clients
> use that to display threads, therefore replying to unrelated email make
> your message appear where it might be missed, or interfere with other
> discussion.

I'm asking seriously.
Sorry for my lack of knowledge. I'm never aware of the ' In-Reply-To header'
before you told me. And more unfortunately, I've ever made several mistakes
before with the feeling that I'm doing the things in a correct and
responsible  manner.

I thank the community for the tolerance to my mistakes, and thank you for
telling
me that. I appologize for the interference I've introduced, even though
that's
not my intention. I am willing to spent minutes of me to save more seconds
of the community to get it a clean and warm place for all of us.
 
Thank you, Volodya.

>
> >> > I'm migrating from 1.38 to 1.39. When building my program,
> >> > I got an link error like this:
> >> >
> >> > LINK : fatal error LNK1104: cannot open file
> >> > 'libboost_thread-vc90-mt-1_38.lib'
> >>
> >> Your program appears to auto-link to 1.38.
> >>
> >> > I've set the correct include path and lib path for the IDE. And I've
> >> > confirmed that
> >> >
> >> > - there's no items in the "Additional Dependendies" in the Liker

section

> > of
> >> > the
> >> > project properties dialog.
> >> > - I've not introduced lib dependendies via #pragma lib directives.
> >> >
> >> > And it's a small program, mainly depends on boost and CGAL.
> >> >
> >> > I have also rebuilt all of the CGAL lib's with boost 1.39.0.
> >> >
> >> > I just cannot how the program depends, directly or indirectly, on
> >> > libboost_thread-vc90-mt-1_38.lib.
> >>
> >> Have you cleaned every single object files that compise your

application.
> >> Are you sure you don't have include paths still pointing at 1.38?
> >
> > Yes, I've also double checked this aspect.
>
> Then, I guess you get to do what Marcus Lindblom suggested -- finding
> which object file grabs that library.

I'll have a try. Thank you, Lindblom and Volodya.

>
> - Volodya
>

B/Rgds
Max

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Emre Turkay-5]

Hi Vladimir,

I think ability to set persistent behavior would be nice. Something like this;

1. convert::set(locale_ = new_locale)(throw_ = true);
2. int i = convert<int>::from(str1, 0);
3. int j = convert<int>::from(str2, 0);

The line #1 effect lines following it (#2 & #3).

Take care,

     emre

On Mon, May 04, 2009 at 02:12:10PM +1000, Vladimir.Batov@... wrote:

> I've incorporated, uploaded to the Vault and started playing with the
> Boost.Parameter-based interface that Andrey Semashev was insisting from
> the set-go. And it is definitely growing on me and I like
>
>         int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
> true);
>
> instead of the original
>
>         int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> I think people generally did not like locales and dothrow behaving like
> manipulators.
>
> The more I use the Boost.Parameter-based interface the more I am inclined
> to push it further and apply it to manipulators as well. I.e.
>
>         int i = convert<int>::from(str)(radix_ = 16);
>
> instead of the original direct handling of std manipulators.
>
>         int i = convert<int>::from(str) >> std::hex;
>
> Something, again, Andrey was advocating from the start. Now it feels like
> allowing io-stream manipulators exposes too much implementation detail and
> raises some unwarranted expectations.
>
> That raises a few questions that I am hoping people could help me with:
>
> 1. Both interfaces (for locale and dothrow) are currently supported:
>
> #1        int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_
> = true);
> #2        int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> Should I remove #1?
>
> 2. Both interfaces
>
> #1        int i = convert<int>::from(str, 0) >> std::hex;
> #2        int i = convert<int>::from(str, 0)(radix_ = 16);
>
> are currently supported. Should I move away from direct manipulator
> support and remove #1?
>
> 3. I only managed to figure out how to supply only one Boost.Parameter at
> a time like
>
>         int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
> true);
>
> I understand how to achieve
>
>         int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ =
> true));
>
> (with double quotes) but do not want to go there as it looks somewhat
> unorthodox. I cannot figure out how to achieve the following
>
>         int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ =
> true);
>
> (a list inside single quotes). I remember Andrey mentioning I could do
> that with a Boost.Parameter macro but I admit of not being bright enough
> to figure it out by myself. Any help would be greatly appreciated.
>
> Thanks,
> Vladimir.
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Scott McMurray-2]

On 2009-05-06, Emre Turkay <emreturkay2@...> wrote:

>
> I think ability to set persistent behavior would be nice. Something like
> this;
>
> 1. convert::set(locale_ = new_locale)(throw_ = true);
> 2. int i = convert<int>::from(str1, 0);
> 3. int j = convert<int>::from(str2, 0);
>
> The line #1 effect lines following it (#2 & #3).
>

I really don't like the idea of global state for this.

Making reusable "format packs" would be nice, though.  Perhaps
instances of the convert class should be allowed, so you could do
something like this?

    convert<int> myconvert((locale_ = new_locale, throw_ = true));
    int i = myconvert.from(str1, 0);
    int j = myconvert.from(str1, 0);

Just musing,
~ Scott
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Batov]

> Scott McMurray wrote:
> ...
> I really don't like the idea of global state for this.

I agree.

> Making reusable "format packs" would be nice, though.  Perhaps
> instances of the convert class should be allowed, so you could do
> something like this?
>
>    convert<int> myconvert((locale_ = new_locale, throw_ = true));
>    int i = myconvert.from(str1, 0);
>    int j = myconvert.from(str1, 0);

Yes, that seems very sensible and seemingly straightforward with
Boost.Parameter argument packs. I'll try playing and implementing the idea.

Thanks,
V.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Emre Turkay-5]

On Fri, May 08, 2009 at 04:39:19PM -0400, Scott McMurray wrote:
> Making reusable "format packs" would be nice, though.  Perhaps
> instances of the convert class should be allowed, so you could do
> something like this?
>
>     convert<int> myconvert((locale_ = new_locale, throw_ = true));
>     int i = myconvert.from(str1, 0);
>     int j = myconvert.from(str1, 0);

This is fine, too.

emre
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams-3]

on Mon May 04 2009, Vladimir Batov <vladimir.batov-AT-wrsa.com.au> wrote:

> Should have proof-read before posting. Apologies.
>
>> Vladimir.Batov <at> wrsa.com.au> writes:
>> 1. Both interfaces (for locale and dothrow) are currently supported:
>>
>> #1 int i=convert<int>::from(str, 0)(locale_=new_locale)(throw_=true);
>> #2 int i=convert<int>::from(str, 0) >> new_locale >> dothrow;
>>
>> Should I remove #1?
>
> Meant to say "Should I remove #2?"
>
>> I understand how to achieve
>>
>> int i=convert<int>::from(str, 0)((locale_=new_locale, throw_=true));
>>
>> (with double quotes) ...
>> (a list inside single quotes).
>
> Certainly meant double *brackets*. Apologies.

You should be able to do it without the double parens.  Is there
documentation missing?

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

On Monday, May 04, 2009 12:12 AM
Vladimir.Batov@... wrote:

[I'm sorry it took so long to reply to this!  I lost your post for a while.]

> I've incorporated, uploaded to the Vault and started playing
> with the Boost.Parameter-based interface that Andrey Semashev
> was insisting from the set-go. And it is definitely growing on
> me and I like
>
>    int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>
> instead of the original
>
>    int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> I think people generally did not like locales and dothrow
> behaving like manipulators.

I was one of them.

> The more I use the Boost.Parameter-based interface the more I
> am inclined to push it further and apply it to manipulators as
> well. I.e.
>
>    int i = convert<int>::from(str)(radix_ = 16);
>
> instead of the original direct handling of std manipulators.
>
>    int i = convert<int>::from(str) >> std::hex;
>
> Something, again, Andrey was advocating from the start. Now it
> feels like allowing io-stream manipulators exposes too much
> implementation detail and raises some unwarranted expectations.

I am quite against this approach.  The whole point of this mechanism is to rely upon the insertion and extraction operators of UDTs (as well as built-ins) for IOStream conversions of one type to another.  You require such operators for the conversion to work.  What otherwise hidden implementation detail is exposed by supporting manipulators on that stream, too?

> That raises a few questions that I am hoping people could help
> me with:
>
> 1. Both interfaces (for locale and dothrow) are currently
> supported:
>
> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>
> Should I remove #1?

You should remove #2, not #1.

> 2. Both interfaces
>
> #1        int i = convert<int>::from(str, 0) >> std::hex;
> #2        int i = convert<int>::from(str, 0)(radix_ = 16);
>
> are currently supported. Should I move away from direct
> manipulator support and remove #1?

#2 provides an interesting, high level abstraction that seems attractive, but only applies to numeric conversions.  The purpose is the same as >> std::hex so, I don't see the value of radix_ when that manipulator is commonly known, documented in the literature, and well understood on sight.  I don't think users can add their own named parameters for convert(), so the library provided named parameters will occupy special status and shouldn't favor one sort of conversion above another.  Consequently, use manipulators when available.

> 3. I only managed to figure out how to supply only one
> Boost.Parameter at a time like
>
>    int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>
> I understand how to achieve
>
>    int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true));
>
> (with double quotes) but do not want to go there as it looks somewhat
> unorthodox. I cannot figure out how to achieve the following

The doubled parentheses are, indeed, rare outside Boost.Preprocessor type code.

>    int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true);

That is certainly preferable syntax.

> (a list inside single quotes). I remember Andrey mentioning I
> could do that with a Boost.Parameter macro but I admit of not
> being bright enough to figure it out by myself. Any help would
> be greatly appreciated.

I have no information to offer on that point.

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Batov]

> From: "Stewart, Robert" <Robert.Stewart@...>
>
> [I'm sorry it took so long to reply to this!  I lost your post for a
> while.]

Hi, Rob, it's nice hearing from you.

> [snip]
>> 2. Both interfaces
>>
>> #1        int i = convert<int>::from(str, 0) >> std::hex;
>> #2        int i = convert<int>::from(str, 0)(radix_ = 16);
>>
>> are currently supported. Should I move away from direct
>> manipulator support and remove #1?
>
> #2 provides an interesting, high level abstraction that seems attractive,
> but only applies to numeric conversions.  The purpose is the same
> as >> std::hex so, I don't see the value of radix_ when that manipulator
> is commonly known, documented in the literature, and well understood
> on sight.  I don't think users can add their own named parameters for
> convert(), so the library provided named parameters will occupy special
> status and shouldn't favor one sort of conversion above another.
> Consequently, use manipulators when available.

Yes, that is *exactly* the conclusion I've come to. #2 indeed looks cute and
aestetically I much prefer #2... but it seems to be merely a sugar coating
over #1. On the other hand, #1 hardly needs *any* explanations/support for
the reasons you mention and that imho makes it a clear favorite. On top of
it, I either do not see how named-parameters-based interface can be made
user-extendable unless we pack all the parameters into ArgumentPacks and
pass them to the user. Maybe that might be the way to pursue in the future
but I feel we pretty much get all that right off the bat with ol'
manipulators-based interface.

>> 1. Both interfaces (for locale and dothrow) are currently
>> supported:
>>
>> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
>> true);
>> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>>
>> Should I remove #1?
>
> You should remove #2, not #1.

Yes, that's what I *actually* meant to say back then. :-) Now though after
having both around I am not sure. As I mentioned I do like
named-parameter-based interface -- I find it pleasant aesthetically (I just
happen to like op()) and friendly. However, while typing I find myself
favoring the frugality and practicality of #2. It is probably because

1) #2 uses the same interface/notation as ">> std::hex" (I admit of being a
consistency/uniformity freak);
2) #2 is less to type (#1 requires using namespace
boost::conversion::parameter;) (surely a weak argument but it saves me a
round trip to the top of the file to add 'using');
3) I do not seem to find any other use for the named-parameter-based
interface beyond locale_ and throw_ (so that the support base for #1 is
somewhat small... although this interface clearly scales better and more
uniformly).

These are just my musings how I torn feel about both rather than serious
arguments for or against.

Best,
V.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stewart, Robert]

Vladimir Batov wrote:

> From: "Stewart, Robert" <Robert.Stewart@...>
>
> >> 1. Both interfaces (for locale and dothrow) are currently
> >> supported:
> >>
> >> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
> >> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
> >>
> >> Should I remove #1?
> >
> > You should remove #2, not #1.
>

12345678901234567890123456789012345678901234567890123456789012345
> Yes, that's what I *actually* meant to say back then. :-) Now
> though after having both around I am not sure. As I mentioned I
> do like named-parameter-based interface -- I find it pleasant
> aesthetically (I just happen to like op()) and friendly.
> However, while typing I find myself favoring the frugality and
> practicality of #2. It is probably because
>
> 1) #2 uses the same interface/notation as ">> std::hex" (I
> admit of being a consistency/uniformity freak);

I like consistency, too, but as Emerson said, "a foolish consistency is the hobgoblin of little minds," so let's not put too much stock in it.

> 2) #2 is less to type (#1 requires using namespace
> boost::conversion::parameter;) (surely a weak argument but it
> saves me a round trip to the top of the file to add 'using');

That's a good argument actually, especially when coupled with...

> 3) I do not seem to find any other use for the named-parameter-
> based interface beyond locale_ and throw_ (so that the support
> basefor #1 is somewhat small... although this interface clearly
> scales better and more uniformly).

Combining the need for a using directive with the lack of named parameters, I find the use of named parameters questionable.  They add compile time overhead and some code complexity for relatively little value.

I have forgotten now the arguments against the following, but I offer it again as a better interface because there's no using directive needed, yet there's a distinction between influencing the convert framework's behavior and the IOStreams conversion operation:

   int i(convert<int>::from(str, 0).locale(new_locale).throw_());

That is, rather than named parameters *or* (to my mind) misusing manipulators, simply use function calls to set those options.  That even permits named functions for related options like classic_locale(), nothrow(), etc., easily providing additional flexibility and expressiveness.

Manipulators added to that convert expression, then, are ordinary manipulators that affect the underlying stream.  There are none that apply to the convert framework while the rest apply to the stream.  Separating the interface to those two parts of the machinery is a wise course, don't you agree?

_____
Rob Stewart                           robert.stewart@...
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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams-3]

on Mon Jun 29 2009, "Stewart, Robert" <Robert.Stewart-AT-sig.com> wrote:

>> 3. I only managed to figure out how to supply only one
>> Boost.Parameter at a time like
>>
>>    int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>>
>> I understand how to achieve
>>
>>    int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true));
>>
>> (with double quotes) but do not want to go there as it looks somewhat
>> unorthodox. I cannot figure out how to achieve the following
>
> The doubled parentheses are, indeed, rare outside Boost.Preprocessor type code.
>
>>    int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true);
>
> That is certainly preferable syntax.

It's not hard to achieve, but I don't think you'd like the effect:

   convert<int>::from(str, 0)

would have to return a function object rather than an int.  What's wrong
with

  int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

?

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Batov]

From: "David Abrahams" <dave@...>
> ...  What's wrong with
>
>  int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

I personally to not feel there is anything wrong per se with the above. The
reason I did not pursue it was that it introduces a limit on the number of
the parameters and I did not see it offering any major advantages to balance
that shortcoming over the supported

int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);

On the other hand the supported interface seems to scale considerably better
and is no longer to type:

int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

V.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vladimir Batov]

> From: "Stewart, Robert" <Robert.Stewart@...>
>> >> #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ =
>> >> true);
>> >> #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow;
>> 1) #2 uses the same interface/notation as ">> std::hex" (I
>> admit of being a consistency/uniformity freak);
>
> I like consistency, too, but as Emerson said, "a foolish consistency
> is the hobgoblin of little minds," so let's not put too much stock in it.

Yes, I've heard that quote. The problem with its applicability here as I see
it is that 1) we have to define what constitutes a *foolish* consistency; 2)
in his "Self-Reliance" Emerson's interpretation of consistency was not even
close to our interpretation of the word within our s/w engineering domain.
Emerson's interpretation (and dismissal) of consistency is clearer when he
elaborates further -- "Speak what you think now in hard words, and to-morrow
speak what to-morrow thinks in hard words again, though it contradict every
thing you said to-day".

So, I feel that the deployment/interface consistency might not be that
easily dismissed with Emerson. Still, I do realize that for better or worse
i/o streams somewhat usurped >> & << operators. That said, I personally do
not feel it is such a hurdle (to me anyway) and I am guilty of using op>>()
for manipulators and locales.

> ...
> Combining the need for a using directive with the lack of named
> parameters,
> I find the use of named parameters questionable.  They add compile time
> overhead and some code complexity for relatively little value.
> I have forgotten now the arguments against the following,
> but I offer it again as a better interface because there's no
> using directive needed, yet there's a distinction between
> influencing the convert framework's behavior and the
> IOStreams conversion operation:
>
>   int i(convert<int>::from(str, 0).locale(new_locale).throw_());

I do not feel (or remember) there might have been arguments against the
interface above. It is an old and humble alternative to Boost.Parameter -
another approach to the "Named Parameter Idiom" described in
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18. Still, I
personally like Boost.Parameter better as I feel it implements the idiom in
a generic and more consistent manner. More so, Boost.Parameter-based
interface is easier to deploy across different conversion specializations.
That said, it'd be ideal to collect more input from the people using
boost::convert. I admittedly have not had much (if any) input but still
hoping that the situation might improve with time and closer to the actuall
review.

> That is, rather than named parameters *or* (to my mind) misusing
> manipulators,
> simply use function calls to set those options.  That even permits named
> functions for related options like classic_locale(), nothrow(), etc.,
> easily providing
> additional flexibility and expressiveness.

Yes, as I said I do not have anything major against this apart from the fact
that I feel Boost.Parameter might fire better accomplishing that.

> Manipulators added to that convert expression, then, are ordinary
> manipulators that affect the underlying stream.  There are none
> that apply to the convert framework while the rest apply to the stream.
> Separating the interface to those two parts of the machinery is a wise
> course, don't you agree?

Well, out of laziness or some other reason I am guilty of simply typing
"convert::from >> std::hex >> locale". I know 'std::hex' and 'locale' affect
different underlying parts. However, on the application level it does not
seem that important to me -- in the end it shapes up the conversion. So, I
am not that determined about "separating the interface to those two parts of
the machinery". It's like my transmission stick and the steering wheel are
two different interfaces to two different parts of machinery. However, I
would not probably mind if I could handle steering and transmission with
just one thing.

V.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams-3]

on Wed Jul 01 2009, "Vladimir Batov" <batov-AT-people.net.au> wrote:

> From: "David Abrahams" <dave@...>
>> ...  What's wrong with
>>
>>  int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);
>
> I personally to not feel there is anything wrong per se with the above. The reason I
> did not pursue it was that it introduces a limit on the number of the parameters and I
> did not see it offering any major advantages to balance that shortcoming over the
> supported
>
> int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
>
> On the other hand the supported interface seems to scale considerably better and is no
> longer to type:
>
> int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true);
> int i = convert<int>::from(str, 0, locale_ = new_locale, throw_ = true);

But again, it has the downside that none of your calls above can return
an actual int.  That can have unexpected effects, e.g. in

   some_function_template( convert<int>::from(str, 0) )

when the deduced template argument is actually your proxy type.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost