First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
A list for the developers of CellML tools

Text archives Help


Re: [[cellml-dev] ] libCellML - Optional values


Chronological Thread 
  • From: Randall Britten <r.britten AT auckland.ac.nz>
  • To: cellml-tools-developers Mailing List <cellml-tools-developers AT lists.cellml.org>
  • Subject: Re: [[cellml-dev] ] libCellML - Optional values
  • Date: Wed, 1 Apr 2015 04:13:53 +0000
  • Accept-language: en-NZ, en-US
If libCellML is asked to load this XML: <model name="">, then the name
attribute in memory would be "".

shared_ptr can’t be used for objects on the stack, and so some other way of
indicating optionality would be needed in that situation.

The key issue is consistency. Boost::optional allows consistent handling of
optionality, whereas other approaches vary in each situation: smart pointers
for dynamic objects, something else for automatics, 0 for integers if they
have to be positive, what for floating point values.

While smart pointers can be used, the above reason shows why this is not
ideal, and also, the, despite the long tradition using pointers and pointer
like things for optionality, this is not their direct semantic intention, and
this is one of the reasons why boost::optional exists in the first place.

Regards,
Randall

From: Richard Christie
<r.christie AT auckland.ac.nz<mailto:r.christie AT auckland.ac.nz>>
Reply-To:
"cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>"

<cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>>
Date: Wednesday, 1 April 2015 4:42 pm
To: cellml-tools-developers Mailing List
<cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>>
Subject: RE: [[cellml-dev] ] libCellML - Optional values

[Sending again with just last message attached, as SYMPA rejected as being
over 40k]

I can’t see why you’d accept an empty string as a valid name, but others may
see it differently.

Are you saying the implementation of std::shared_ptr requires dynamic
allocation even for returning an existing object?

Smart pointers have the capability to represent optional values, and it’s no
crime to use them for this. Wrapping them in another layer of optionality is
unnecessary redundancy.

Regards,
Richard


From:
cellml-tools-developers-request AT lists.cellml.org<mailto:cellml-tools-developers-request AT lists.cellml.org>

[mailto:cellml-tools-developers-request AT lists.cellml.org]
On Behalf Of Randall Britten
Sent: Wednesday, 1 April 2015 4:02 p.m.
To: cellml-tools-developers Mailing List
Subject: Re: [[cellml-dev] ] libCellML - Optional values

Hi Richard

Empty string is a valid value for e.g. the model name attribute, and hence
not suitable as a replacement for boost::none.

std::shared_ptr requires dynamic allocation, and it’s purpose is to ensure an
object is deleted when all references are out of scope. Although its
uninitialised state can be used to indicate the absence of a value, that is
not its primary design semantic. If we were to use shared_ptr (or some other
smart pointer) only for objects, then we still would have to handle the case
for values (e.g. floating point values, or cases where all integer values are
valid), so it would mean that there is a lack of consistency in the codebase.

Using boost::optional in all cases means that the semantics is consistent and
clear. Even if a boost::optional wraps a smart pointer, then it improves the
ability to find invalid states, e.g. if a value is not boost::none, but the
smart pointer is uninitialised, then something has gone wrong.

Regards,
Randall

Archive powered by MHonArc 2.6.18.

Top of page