Chronological Thread 

< Chronological >      < Thread >

---

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.