Function chaining and data loss

Question

When I started with c++ initially, we were taught that function chaining work only with return value by reference. Otherwise data loss occurs if we use return by value.

If I remember correctly, it was for assigning three objects in a single line for assignment operator overloading.

Is above still correct?

I heard today that builder pattern can return builder object by value and it should not be a problem of data loss. Performance may hit but data loss is not the concern.

Answer 1

The answer to this is rather simple.

When you return Car&, you return the address of the object (the very object that u are dealing with, the original).

But when you return Car, you return a new object that is a copy of the original (hence if u modify this copy, the original is unchanged).

So in ur code, u do:

`
myCar.setModel("Ford").setYear(2025);
`

The setModel method is used on the myCar object. Then this function returns a COPY of the myCar object, which is then used with setYear function. Hence u change the year of the copy, not the original.

you can fix this with one of the following:

`
Car myCar;
myCar.setModel("Ford");
myCar.setYear(2025);
myCar.displayInfo();
`

This way both functions are used on the original object.

You can also technically just reassign myCar to the new object:

`
Car myCar;
myCar = myCar.setModel("Ford").setYear(2025);
myCar.displayInfo();
`

But ofc this is terrible design pattern, which shouldn't be used. just return an address smh

Answer 2

Function chaining is nice to use for builder kind of patterns, which is exactly what you are doing it seems. Harder to debug? not sure why someone would say that. the goal of this pattern is to make it easy and sexy for the end user.

Sexy code first and foremost always. Love chainable functions. ♥️

object.method()
.method2()
.method3()
.method4();

Keeping the dots in line is highly fashionable

Answer 3

Ketan Lalcheta
you need to return the object reference because it's the common basis for all the chained methods.

you can see this in your code. you can only set the model, but the chained year method was not applied because it was not being applied to the Car&. By not returning Car&, the chain is broken, so your display have year=0.

it seems to be unnecessary in the display() method, but by still returning Car&, we can continue chaining methods for as long as we want.

Answer 4

Aleksei Radchenkov
it's good for confusing people and writing fancy looking codes 😁
but I agree, it does not fundamentally improve the code.

Answer 5

😁 Mortal Kombat!!
The Witcher vs Aleksei Radchenkov
FIGHT!

just joking, but yes, it's mostly personal preferences vs code style policies.

Answer 6

Bob_Li Exactly just a style preference. No real definite rules in coding. But if there is a place for chaining functions in peoples hearts, it is definitly with builder patterns.

Answer 7

The Witcher , Aleksei Radchenkov and Bob_Li

Builder pattern is cool for sure.

I also used to use it like anything , but one use case draw my attention and then I went back to function chaining and started this thread.

Please refer attached code.

Builder pattern works well unless end user do not unintentionally break it.

Basically don't create last car object (car4) from l value ref of builder (builder3) as it is undefined behaviour.

Thanks again for making this question engaging.
https://sololearn.com/compiler-playground/c8V7AtW754ZC/?ref=app

Answer 8

can you post a sample code?

can you elaborate a bit more about the data loss part?

the simplest method chaining implementation I can think at the moment looks something like this:

https://sololearn.com/compiler-playground/ck8m0D7ZcEGJ/?ref=app

but i would avoid using this pattern because it's harder to debug when something goes wrong.

Answer 9

Bob_Li thanks for putting this sample code.

Why you had returned Car& from all the method ? You could have returned simple car from each method .

Is it not necessary to return Car&

Answer 10

Bob_Li here is the trial finally. I could still reproduce this it seems.

Means inconsistent behaviour apart from copy constructor cost.

Refer code below:

https://sololearn.com/compiler-playground/cOYfNI37BKT0/?ref=app

It results into data loss. If I had all the methods returning &, we could have proper results.