[C++-sig] Re: (return_self_policy / return_arg): Keywors

David Abrahams dave at boost-consulting.com
Sat Jul 5 02:05:59 CEST 2003


Nikolay Mladenov <nickm at sitius.com> writes:

> David Abrahams wrote:
>> OK, I would like to see "irrelevancies" removed from the code for any
>> test case, though... unless you think the efficiency issue is closely
>> related to the keyword support, in which case you'll have to convince
>> me (please).
>
> I am not sure what needs convincing? There is an efficiency issue. Don't
> you agree?

I suppose so.  I meant that if you want to keep those extra
constructors in the examples or tests for this feature I want to be
convinced that they're relevant.  It sounds like you don't want to
keep them, though.

> I put those just so to answer you question on why I have redundant
> constructor.

Thanks.

> I don't mean to keep them
>
>
>> 
>> >> Why are you using no_init?
>> >
>> > For the same reason, not that it makes sence for my first example,
>> > but in general, I want my most offsen called overload to be first in
>> > the list - so defined last.
>> 
>> That still doesn't explain why you'd want to use no_init.  Why not
>> just define the more-important constructor 2nd?
>
>
> Are you saying that I should put the first constructor as parameter of
> the class_ constructor?

Well, at least you *could*.

> Cause I really prefer the def way for exporting constructors.

I can understand that.

> I was not realizing the fact that class_() implicitly defines
> default constructor for a long time, and I think that this is
> somewhat confusing.

Understandable.  People were even more confused when BPL allowed them
to write classes that couldn't be constructed by default.

Maybe we should deprecate the def() way and provide a mechanism for
chaining init<...>() instances in the class_<...> constructor
(e.g. with commas).  At least that would focus all attention in the
same place.


>> >> ...and shouldn't we get rid of the need to write the outer
>> >> "args(...)"?
>> > It is not necessary to have it, you can write
>> >       (arg("a") = (int)0, arg("b") = (double)0, arg("n") = std::string()))
>> > instead of
>> >       args(arg("a") = (int)0, arg("b") = (double)0, arg("n") =
>> > std::string()))
>> > but you'll probably want
>> >       args("a","b","c", arg("n") = std::string()))
>> > instead of
>> >       (arg("a"), arg("b"), arg("c"), arg("n") = std::string()))
>> 
>> Understood... but is it really wise to give people more than One (And
>> Preferably Only One) Obvious Way To Do It?
>
>
> Why not? 

It's "unpythonic".  Have you tried

     >>> import this

<wink>?

> They are not *too* different, are they?

Sometimes things which are almost the same but subtly different are
worse than things which are very different.  It bothers me to have
two things like that whose name differs only in plurality.

>> I might be inclined to support only:
>> 
>>   args("a","b","c")
>> 
>> and:
>> 
>>   (arg("a"), arg("b"), arg("c"), arg("n") = std::string()))
>> 
>> Or even drop the 1st and go with
>> 
>>   (arg("a"), arg("b"), arg("c"))
>> 
>> Thoughts?
>
>
> Well, originally I thought that args() is already in the library so
> it should not be removed.

We could keep it for backward compatibility but deprecate it by
removing it from the docs.

> So if you insist on being minimal

I don't insist on it, but I think it might be a good idea.

> than probably we should support
>
> 	args("a","b","c") // which is already there

Grr...

> 	arg("d")=1 

I like this one.

> and at the end:
>
> 	( args("a","b","c"), arg("d")=1, arg("e")=std::string() ) 

Grr...
What about

 	( arg("a"),"b", "c", arg("d")=1, arg("e")=std::string() ) 

Instead?

> 	( arg("a"), arg("d")=1, arg("e")=std::string() ) 

Fine.

-Dave

P.S. I'm not terribly convinced of my own position here.  Any bit of
additional resistance from you and I'll probably cave ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com





More information about the Cplusplus-sig mailing list