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: "Alan Garny" <alan.garny AT inria.fr>
  • To: <cellml-tools-developers AT lists.cellml.org>
  • Subject: RE: [[cellml-dev] ] libCellML - Optional values
  • Date: Mon, 13 Apr 2015 23:11:28 +0200
  • Organization: INRIA
This seems like a good compromise to me.

Alan

> -----Original Message-----
> From:
> cellml-tools-developers-request AT lists.cellml.org
> [mailto:cellml-tools-
> developers-request AT lists.cellml.org]
> On Behalf Of Jonathan Cooper
> Sent: 13 April 2015 14:59
> To:
> cellml-tools-developers AT lists.cellml.org
> Subject: Re: [[cellml-dev] ] libCellML - Optional values
>
> 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/


Archive powered by MHonArc 2.6.18.

Top of page