Chronological Thread 

< Chronological >      < Thread >

---

Hi all,
Just a quickie, but personally I'd be inclined to use boost::optional for the semantic clarity, but probably ship the header with the API to avoid an external dependency.
Best wishes,
Jonathan

On 12/04/2015 01:28, Gary Mirams wrote:

Hi all,

In Chaste we introduced boost for compilcated things like
serialization, but we've tried to avoid using it for everything
because it is an extra set of syntax to learn, and extra work
maintaining compatibility between versions. For instance we switched
to using boost random number generators, but to maintain the same
random numbers between versions of boost we have ended up doing a fair
bit of work re-implementing lots of the boost methods to override old
versions and horrible things like that!

So for simpler things like this I would be more than happy with
'empty' meaning there is no argument. As for an empty model name - I
can't see any reason why this should be allowed.

Look forward to meeting you all at the workshop.

Cheers,

Gary

On 1 April 2015 at 17:13, Randall Britten
<r.britten AT auckland.ac.nz>
wrote:

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>
Reply-To:
"cellml-tools-developers AT lists.cellml.org"
<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>
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]
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

--
Dr Gary Mirams
Wellcome Trust & Royal Society Sir Henry Dale Fellow
Computational Biology,
Dept. of Computer Science,
University of Oxford,
Wolfson Building,
OX1 3QD.
+44 (0)1865 610671
http://www.cs.ox.ac.uk/people/gary.mirams/

---

• [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
  • RE: [[cellml-dev] ] libCellML - Optional values, Richard Christie, 04/01/2015
    • Re: [[cellml-dev] ] libCellML - Optional values, David Brooks, 04/01/2015
      • Re: [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
        • RE: [[cellml-dev] ] libCellML - Optional values, Richard Christie, 04/01/2015
          • Re: [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
            • RE: [[cellml-dev] ] libCellML - Optional values, Richard Christie, 04/01/2015
              • Re: [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
  • <Possible follow-up(s)>
  • Re: [[cellml-dev] ] libCellML - Optional values, Gary Mirams, 04/12/2015
    • Re: [[cellml-dev] ] libCellML - Optional values, Jonathan Cooper, 04/14/2015
      • RE: [[cellml-dev] ] libCellML - Optional values, Alan Garny, 04/14/2015

---

Archive powered by MHonArc 2.6.18.