[haiku-development] Re: Problem with BMessage and SettingsMessage

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Sun, 18 Apr 2021 16:24:58 +0100

Hi!

On Fri, Apr 16, 2021 at 11:00 AM Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:


const void*
SettingsMessage::GetValue(const char* name, type_code type, ssize_t 
numBytes, const void&
defaultValue)

This will not work, because what address are you going to return in
case of success? The idea of BMessage::FindData() is that you write
the outcome to a void* buffer, not create a new buffer.

That's not right, actually FindData 
(https://www.haiku-os.org/legacy-docs/bebook/BMessage.html#BMessage_FindData)
takes a pointer-to-pointer as a parameter, and on return, the pointed pointer 
points directly inside the BMessage data
(don't you love C++ for allowing these crazy things?).

You're right! My mistake I did not look far enough.

So, this would work, but you have to remember that your data is owned by the 
BMessage, and if the BMessage
is deleted/goes out of scope, you are left with an invalid pointer.

Yes. Arguably it's almost a bad design.

Having said that, I find it difficult to understand what the value of
the GetValue() overloaded methods is, when there are BMessage::Get*()
methods that are also available.

If I remember this correctly, the idea of SettingsMessage is to add the 
handling of "defaults/revert".
So, all calls to Set* will track if the settings are modified, and all calls 
to Get* will return the
default value if nothing is present in the message being loaded.

Given my oversight about BMessage::FindData(), it actually would make
sense to have the semantics of SettingsMessage::GetValue() to be to
take an input parameter with a default value, and copy over the data
in the underlying message if there is anything. That makes sure that
nobody is borrowing data out of the message, and there is no need to
worry about the lifetime of the message, or writes that alter the data
layout.

Regards,

N>

Other related posts: