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 02:16:35 +0000
  • Accept-language: en-GB, en-NZ, en-US
Checking optional attributes that are objects is handled by operator bool()
on std::shared_ptr and other smart pointers.
That leaves strings and possibly other base types.
Following are ideas:
Empty string could be used for strings; operator==() defines variants with
C-strings. User can write if (name == "") { }
Integer attributes are often invalid for zero or negative values.
Real numbers are the difficult ones, but are there any outside of math?

Aside: are there problems exposing STL classes in your public API? I.e. even
with the same name mangling can you have problems between different versions
of the same compiler?

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 2:40 p.m.
To: cellml-tools-developers Mailing List
Subject: Re: [[cellml-dev] ] libCellML - Optional values

Thanks for your replies David and Richard, you've both requested more info,
so here goes:

Boost optional is "header only". As I said previously, any other use of
Boost would have to go through review anyway.
The case for using boost::optional is fairly strong: All possible string
values could occur if the attribute was present. This is the standard use
case for boost::optional, i.e. there are no "special" values that can be used
to indicate the absence of a value.
Other cases that I encountered: pretty much every single
relationship/property in a CellML model, since libCellML needs to be able to
handle incomplete models, so any attribute might be missing, e.g. Variable
name, variable units, component name, import URL, any of the attributes on a
unit element, etc. It will depend to what extent libCellML is required to
provide access to invalid/incomplete/under-construction models though.

One alternative is to use pointers (or std::unique_ptr), but then that
entails dynamic allocation, and extra documentation to remind the caller that
null actually is intended to communicate "value not present", thus the code
is not self-documenting, and hence more error-prone.
See
http://stackoverflow.com/questions/14360706/when-to-use-boostoptional-and-when-to-use-stdunique-ptr-in-cases-when-you-wa
for a discussion.
For other reasons for avoiding a raw pointer, see
http://stackoverflow.com/a/17008158/2727805

Another option is to copy just the code for boost::optional, but since Boost
is virtually a standard, I think it is preferable to use Boost properly.
Using bcp is an option, but at this stage we have boost set up, and there
seems no reason to use bcp now.

If different versions of boost are ever needed, boost provides mechanisms for
doing this gracefully (see
http://www.boost.org/doc/libs/1_57_0/tools/bcp/doc/html/index.html), but I
think that is probably an edge case that is not highly relevant to our
decision, so I'd recommend we proceed, and cross that bridge if we ever need
to.

I'll summarise the analysis once I've given more time for others to respond,
then we can have a table of pros and cons.

At this stage, I won't mock-up alternatives, since I do not see any
alternatives worth exploring further yet, but if someone suggests a better
alternative, I'd be happy to look at it.

Regards,
Randall

From: David Brooks
<d.brooks AT auckland.ac.nz<mailto:d.brooks 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 1:23 pm
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>>,

"cellml-tools-developers AT cellml.org<mailto:cellml-tools-developers AT cellml.org>"

<cellml-tools-developers AT cellml.org<mailto:cellml-tools-developers AT cellml.org>>
Subject: Re: [[cellml-dev] ] libCellML - Optional values

In general I agree with Richard's points. However a lot of Boost's
functionality is provided at compile time (via its headers) and only a few
modules depend on the use of a libraries. What is the case for
boost::optional ??

In the specific example, if an empty string is not a valid value for a name
then I would return the empty string when the name is missing.


Regards,
Dave

On 1/04/15 12:52 pm, Richard Christie wrote:
I'd be disinclined to have dependencies on other libraries in any public API
unless they performed a critical part of the actual work, not a trivial
feature such as this.
You have to deal with delivery of the additional libraries and headers and
any future version issues. Also, your clients' code is exposed to extra
libraries they possibly didn't want, different versions of boost etc.
Finally, the client usage of the API is modified e.g. you can't just use the
return value where a string is required.

In this case I'd expect a more thorough analysis of the issue and benefits.
You've only mentioned a string name attribute, can you list any others and
for which classes? Is an empty string a valid name? Can you mock up client
code variants for the possible alternatives?

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 10:50 a.m.
To:
cellml-tools-developers AT cellml.org<mailto:cellml-tools-developers AT cellml.org>
Subject: [[cellml-dev] ] libCellML - Optional values

Hi all

A few months ago, I wrote code that got through the first few use cases.
This highlighted the need to handle optional values. For example, if an XML
file is loaded into memory, and say the model element was missing the name
attribute, then the in-memory representation would return boost::none when
model.getName() was called. (Even though a model is not valid without a name
attribute, libCellML will allow processing of models that are not valid, for
example, when continuing the authoring of a partially complete model.) Using
boost::optional from the Boost library seems to be technically superior by
far than other approaches, for example using pointers, or having additional
methods, e.g. model.hasName().

David Nickerson has expressed that he prefers not to use Boost in the public
API.

Boost is pretty standard, and certainly is a well-respected library.
boost::optional itself is fairly straightforward to use.

Other uses of boost may be esoteric, and I too would rather avoid those, but
that does not mean we should reject the entire library outright, rather, we
should just assess each use of Boost on a case-by-case basis during code
review.

Please send us your feedback, we'd like to hear from the community.

Regards,
Randall Britten
______________________________________________
Bioengineering Software Development Specialist
Auckland Bioengineering Institute
University of Auckland
Auckland, New Zealand
www.abi.auckland.ac.nz<http://www.abi.auckland.ac.nz>




Archive powered by MHonArc 2.6.18.

Top of page