Prev: How to test if a iterator is valid or not?
Next: return value optimization vs. returning a boost::shared_ptr of container
From: Goran on 16 Jun 2010 21:01
On Jun 16, 3:56 pm, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote:
> Goran wrote:
> > On Jun 15, 11:15 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote:
> >> Hi,
>
> >> I have an object:
>
> >> class SomeObject
> >> {
> >> public:
> >> SomeObject();
>
> >> SomeObject& setValue( int i );
> >> SomeObject& increaseRate( int percent );
> >> ... etc ...
>
> >> };
>
> >> This is used in the following manner
>
> >> startCalculation( SomeObject().setValue( 47 ).increaseRate( 20 ) );
>
> > I've seen code like this (even wrote some in my time), and I've come
> > to despise it. The major problem I see with this is that your
> > modifiers are misleading in form. What they buy is the ability to call
> > multiple methods on an object in one statement. Uh-oh, big deal.
>
> I'm in a design phase right now and need all input I can get. Can you
> please explain a bit further; what part is it that you don't like? Is it
> the function chaining, the temporary object, both, or something else?

I don't like that object reference returned. Your methods are
modifiers. They are by definition void. So what is that reference that
is returned? *this? An embedded object with changed value? A new
object (God forbid that) with changed value?

Sure, I am exaggerating, it's clear enough, but is it worth the hassle
given what it buys?

> >> Now, I want to provide a small wrapper ensuring correct initialization.
>
> > Erm... That's what constructor is for?
>
> > On a more general note, it looks like you are using two-step
> > initialization. In my opinion, there has to be a big fat explanation
> > for every use. So what's your excuse? ;-)
>
> As Daniel Kr�gler guessed, I'm not allowed to change the constructor of
> SomeObject, and even if I could, the number of permutations would be
> gastronomical.
>
> One could see SomeObject as a general settings object where the normal
> use would be
>
> startCalculation( SomeObject().setValue( 47 ).increaseRate( 20 ) );
>
> while better compile-time safety could be achieved, forcing some of the
> optional parameters be mandatory, with wrapper helpers like so
>
> startCalculation( PreparedObject( 47, 20 ) );
>
> or even
>
> startCalculation( IncreasedRate20( 47 ) );
>
>
>
> >> My question is; shall I use derivation or a function? I.e.
>
> >> struct PreparedObject : SomeObject
> >> {
> >> inline PreparedObject( int i, int percent ) : SomeObject()
> >> {
> >> (*this).setValue( i ).increaseRate( percent );
> >> }
>
> >> }
>
> >> or shall I use a function:
>
> >> inline SomeObject preparedObject( int i, int percent )
> >> {
> >> return SomeObject().setValue( i ).increaseRate( percent );
>
> >> }
>
> >> Later those would be used like this
>
> >> startCalculation( PreparedObject( 47, 20 ) );
>
> > If this is __really__ the only way you are happy with :-), I'd say
> > that a function is better, simply because it's less code artifacts.
> > (Derivation meant a class and a trivial ctor. That's incidental
> > complexity, not much more)
>
> A function may seem the obvious choice for most here, but to be picky,
> will I not get a slight performance hit compared to derivation since I
> have to return the object? Or will the function inlining take care of that?

Given today compilers, almost certainly.

TYPE func(params)
{
TYPE t;
init t;
return t;
}

TYPE my_t(func(params));

The above effectively compiles to:

void func(TYPE& t, params)
{
init t;
}

TYPE my_t;
func(t, params);

Goran.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Hakusa on 16 Jun 2010 22:37
On Jun 16, 9:56 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote:

> As Daniel Kr�gler guessed, I'm not allowed to change the constructor of
> SomeObject, and even if I could, the number of permutations would be
> gastronomical.

What about applying a factory pattern? Pseudo-code:

SomeObFact factory;
factory.set_value( x );
factory.increase_rate( y );

SomeObject obj = factory.make();

Alternately, i wonder if you could make a child of SomeObject that
accepts the factory for its constructor.

> A function may seem the obvious choice for most here, but to be picky,
> will I not get a slight performance hit compared to derivation since I
> have to return the object? Or will the function inlining take care of that?

If you're THAT worried, maybe my factory suggestion wouldn't be
optimal... Still thought i'd put it out there.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: DeMarcus on 18 Jun 2010 00:31
On 2010-06-17 14:01, Goran wrote:
> On Jun 16, 3:56 pm, DeMarcus<use_my_alias_h...(a)hotmail.com> wrote:
>> Goran wrote:
>>> On Jun 15, 11:15 am, DeMarcus<use_my_alias_h...(a)hotmail.com> wrote:
>>>> Hi,
>>
>>>> I have an object:
>>
>>>> class SomeObject
>>>> {
>>>> public:
>>>> SomeObject();
>>
>>>> SomeObject& setValue( int i );
>>>> SomeObject& increaseRate( int percent );
>>>> ... etc ...
>>
>>>> };
>>
>>>> This is used in the following manner
>>
>>>> startCalculation( SomeObject().setValue( 47 ).increaseRate( 20 ) );
>>
>>> I've seen code like this (even wrote some in my time), and I've come
>>> to despise it. The major problem I see with this is that your
>>> modifiers are misleading in form. What they buy is the ability to call
>>> multiple methods on an object in one statement. Uh-oh, big deal.
>>
>> I'm in a design phase right now and need all input I can get. Can you
>> please explain a bit further; what part is it that you don't like? Is it
>> the function chaining, the temporary object, both, or something else?
>
> I don't like that object reference returned. Your methods are
> modifiers. They are by definition void. So what is that reference that
> is returned? *this? An embedded object with changed value? A new
> object (God forbid that) with changed value?
>

Yes, it returns *this. I use function chaining, or the Named Parameter
Idiom as explained in FAQ Lite.
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18


> Sure, I am exaggerating, it's clear enough, but is it worth the hassle
> given what it buys?
>

I think function chaining is pretty neat, but I try to find out whether
function chaining is the way to go.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: DeMarcus on 18 Jun 2010 01:18
On 2010-06-16 19:46, Jeff Flinn wrote:
> DeMarcus wrote:
>> Paul Bibbings wrote:
>>> DeMarcus wrote:
>>>> Hi,
> ...
>> All ideas about optional parameters are welcome. Thanks for your input!
>
> Have you looked at
> http://www.boost.org/doc/libs/1_43_0/libs/parameter/doc/html/index.html
>
> Abstract:
>
> Use this library to write functions and class templates that can accept
> arguments by name:
>
> new_window("alert", _width=10, _titlebar=false);
>
> Since named arguments can be passed in any order, they are especially
> useful when a function or template has more than one parameter with a
> useful default value. The library also supports deduced parameters; that
> is to say, parameters whose identity can be deduced from their types.
>
> Jeff
>

Thanks! I didn't know about that tool. I also found another neat
parameter trick when I was looking at boost exceptions.

http://www.boost.org/doc/libs/1_40_0/libs/exception/doc/error_info.html

Here they use an empty struct as parameter identifier.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: DeMarcus on 18 Jun 2010 01:18
On 2010-06-17 15:37, Hakusa(a)gmail.com wrote:
> On Jun 16, 9:56 am, DeMarcus<use_my_alias_h...(a)hotmail.com> wrote:
>
>> As Daniel Kr�gler guessed, I'm not allowed to change the constructor of
>> SomeObject, and even if I could, the number of permutations would be
>> gastronomical.
>
> What about applying a factory pattern? Pseudo-code:
>
> SomeObFact factory;
> factory.set_value( x );
> factory.increase_rate( y );
>
> SomeObject obj = factory.make();
>
> Alternately, i wonder if you could make a child of SomeObject that
> accepts the factory for its constructor.
>

In this particular case I think a factory will not work, however, I've
been considering using some helper class of some kind, so using a
factory is not far from a good solution.

>> A function may seem the obvious choice for most here, but to be picky,
>> will I not get a slight performance hit compared to derivation since I
>> have to return the object? Or will the function inlining take care of that?
>
> If you're THAT worried, maybe my factory suggestion wouldn't be
> optimal... Still thought i'd put it out there.
>
>

Well, honestly, I usually don't care that much about performance. I
rather get the design right. But in this particular case we had two
almost identical solutions; derivation and function wrapping. Then I
feel that it could be a good idea to have a look at which one performs best.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: How to test if a iterator is valid or not?
Next: return value optimization vs. returning a boost::shared_ptr of container