Ancestors

Toot

Written by Paul Targosz 🦦 on 2025-01-17 at 09:07

Can the mighty mastodonverse help me?

i'm doing some teaching lessons and i can't think of an good example for function in c++ that have different implementations for "by ref" and "by val" for function parameters.

i have enough for each, but not one example where both version would be relevant.

=> More informations about this toot | More toots from sickeroni@mastodon.social

Descendants

Written by Daniel Evers on 2025-01-17 at 20:25

@sickeroni

Shall they have the same or similar semantics?

This reminds me of utilities like boost::trim. Calling by value could return a trimmed copy while calling by reference would trim in-place.

=> More informations about this toot | More toots from dermojo@hachyderm.io

Written by Paul Targosz 🦦 on 2025-01-19 at 10:56

@dermojo mhh i need to take a deeper lok in it. I read your explaination, but couldn't see it in code. but maybe i just need a small break :D

=> More informations about this toot | More toots from sickeroni@mastodon.social

Written by Dani (:cxx: modules addict) on 2025-01-19 at 11:29

@sickeroni @dermojo Shouldn't be the distinction more along the line of object independence, and the rest follows from there?

You have two cases:

1. you got an independent object (i.e. by-value function parameter), or a reference to a materialized pr-value / abandoned x-value. Then you can manipulate such an object to your hearts content whereever it currently lives. It's yours.

2. you're dealing with an object outside your control. In other words: you got a l-value reference. Now you have two sub-cases:

• the function parameter refers to a constant object that you may only observe. If this doesn't suffice, this means you have to create a copy before or during manipulation.

• the parameter refers to a non-constant object. Now you're stumped:

• this could be an old-fashioned in-out or out parameter with unclear semantics that you should avoid anyway

• this could be meant to be manipulated in place

• this could be meant to be treated like a const reference and the programmer was sloppy and didn't think about concurrency

• this could mean something else

I hope this leads you to an example that demonstrates your teaching intent.

[#]cpp

=> More informations about this toot | More toots from DanielaKEngert@hachyderm.io

Written by Peter Sommerlad on 2025-01-19 at 11:56

@DanielaKEngert @sickeroni @dermojo

very nice categorization that i will steal for my teaching.

one thing is missing wrt references: dynamic polymorphism with virtual requires them.

=> More informations about this toot | More toots from PeterSommerlad@mastodon.social

Written by Dani (:cxx: modules addict) on 2025-01-19 at 12:00

@PeterSommerlad @sickeroni @dermojo That's very much true, but I refrained from digging into this rabbit-hole because I didn't get the impression that Paul was looking after that 😀

Thank you for your blessing 😎

=> More informations about this toot | More toots from DanielaKEngert@hachyderm.io

Written by BLeichtle on 2025-01-20 at 06:50

@DanielaKEngert @sickeroni @dermojo assuming the same method signature - the use case matters,too. Using a do_something(const auto& x) is fine until you step into the land of parallel processing (combined with the use of std::generator I promise ugly runtime problems) and this is prevented by a local copy using do_something (val) - dangling references are nasty

=> More informations about this toot | More toots from BLeichtle@sueden.social