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: Richard Christie <r.christie 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 03:42:54 +0000
  • Accept-language: en-GB, en-NZ, en-US
[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

Archive powered by MHonArc 2.6.18.

Top of page