ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005220 | Part 06: TTCN-3 Control Interface | Clarification | public | 02-06-2009 14:44 | 18-03-2010 07:40

Reporter | Ina Schieferdecker |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.2.1 (published 2010-07) | Fixed in Version | v4.2.1 (published 2010-07) |
Clause Reference(s) | TCI C++ mapping clause
Source (company - Author) | INRIA, France

Summary | 0005220: TCI C++ Mapping Issues

Description

1. The C++ mapping introduced in this new version of the interface uses
design conventions that are Java-like and are not easily interoperable
with the C++ standard libraries.
eg:
> class TciModuleIdList {
> public:
> virtual ~TciModuleIdList();
> virtual Tsize size () const =0;
> virtual Tboolean isEmpty () const =0;
--> should be virtual Tboolean empty() const =0;
> virtual const std::vector< const TciModuleId * > & getComponents ()
> const =0;
--> this puts too much design constaints on the implementation of the interface
(especially the TciModuleId needs to be stored in a vector of pointers)
> virtual const TciModuleId &get (Tsize p_index) const =0;
--> should be :
virtual const TciModuleId &at (Tsize p_index) const =0;
virtual const TciModuleId operator[] (Tsize p_index) const =0;
> virtual void clear ()=0;
> virtual void add (const TciModuleId &comp)=0;
--> should be :
virtual void push_back (const TciModuleId &comp)=0;
> virtual Tboolean equals (const TciModuleIdList &midList) const =0;
--> should be :
virtual Tboolean operator== (const TciModuleIdList &midList) const =0;
> virtual TciModuleIdList * cloneModuleIdList () const =0;
--> should be : virtual TciModuleIdList * clone () const =0;
> virtual Tboolean operator< (const TciModuleIdList &midList) const =0;
> }
2. Section 10.5 is self-contradictory
> Pure virtual classes have been used, following the concept of an interface.
> The Standard Template Library (STL) has been used as it is a standardized
> way of using container classes, and iterators, such as lists. All classes
> define the operator "<" for easy insertion in STL containers.
The STL containers require that the contained class is
copy-constructible. However the classes in the C++ mapping are not
copy-constructible (the are abstract base classes containing pure
virtual functions), therefore they cannot be used in STL containers.
Moreover, some STL containers require the operator '==' instead of '<'
(eg: unordered_set and unordered_map)

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | es_20187306v040102.zip (1,317,758) 18-03-2010 07:40 http://oldforge.etsi.org/mantis/file_download.php?file_id=2340&type=bug

Issue History
Date Modified | Username | Field | Change
02-06-2009 14:44 | Ina Schieferdecker | New Issue |
02-06-2009 14:44 | Ina Schieferdecker | Status | new => assigned
02-06-2009 14:44 | Ina Schieferdecker | Assigned To | => Ina Schieferdecker
02-06-2009 14:44 | Ina Schieferdecker | Clause Reference(s) | => TCI C++ mapping clause
02-06-2009 14:44 | Ina Schieferdecker | Source (company - Author) | => INRIA, France
05-06-2009 11:40 | Anthony Baire | Note Added: 0008724 |
05-06-2009 11:52 | Anthony Baire | Note Added: 0008725 |
08-06-2009 13:54 | JesÃºs DomÃnguez | Note Added: 0008730 |
10-06-2009 18:44 | Anthony Baire | Note Added: 0008738 |
15-06-2009 14:15 | Raul Alfonso | Note Added: 0008770 |
30-06-2009 10:21 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 06: TTCN-3 Control Interface
30-06-2009 10:21 | Ina Schieferdecker | Category | TCI => Clarification
30-06-2009 10:21 | Ina Schieferdecker | Target Version | => Edition 4.2.1 (not yet published)
06-07-2009 15:48 | Anthony Baire | Note Added: 0008847 |
06-07-2009 15:48 | Anthony Baire | Note Edited: 0008847 |
18-03-2010 07:39 | Ina Schieferdecker | Status | assigned => resolved
18-03-2010 07:39 | Ina Schieferdecker | Resolution | open => fixed
18-03-2010 07:39 | Ina Schieferdecker | Fixed in Version | => Edition 4.2.1 (not yet published)
18-03-2010 07:40 | Ina Schieferdecker | File Added: es_20187306v040102.zip |
18-03-2010 07:40 | Ina Schieferdecker | Status | resolved => closed

Notes

(0008724)
Anthony Baire
05-06-2009 11:40

Here is a proposal for the replacement for the getComponents() function (and the similar function founds in other container classes)
> virtual const std::vector< const TciModuleId * > & getComponents () const =0;
As stated before, this function should be removed because it puts too much design constaints on the implementation of the interface (it mandates that the object stores the TciModuleId list in a vector of pointers).
In order to provide similar features, all the interface classes that provide access to a list of elements should support the Range concept, i.e: provide the following definitions:
typedef ##implementation_defined## const_iterator;
const_iterator begin() const;
const_iterator end() const;
The type of const_iterator is implementation defined. It shall comply with the InputIterator concept (http://www.cplusplus.com/reference/std/iterator/InputIterator/ [^]) and the dereferencement operator shall return a const reference on the contained object.
eg: - TciModuleList::const_iterator::operator*() shall return const TciModuleId&
- TciModuleList::const_iterator::operator->() shall return const TciModuleId*
Supporting the range concept allows inspecting easily the content of the objects using itarators.
eg. using the boost foreach library
#include <boost/foreach.hpp>
...
TciModuleIdList& m_list;
...
BOOST_FOREACH (const TciModuleId& id, m_list) {
...
}
eg. using the range-based loops in the upcoming version of the c++ standard
TciModuleIdList& m_list;
...
for (const TciModuleId& id : m_list) {
...
}

(0008725)
Anthony Baire
05-06-2009 11:52

Regarding section 10.5, the following text should be removed (or possibly replaced with a paragraphe about the Range concept above if accepted):
> The Standard Template Library (STL) has been used as it is a standardized
> way of using container classes, and iterators, such as lists. All classes
> define the operator "<" for easy insertion in STL containers
The rationale for the deletion is that this paragraph is confusing since it is not possible to insert objects that are not copy-constructible into STL containers.
[Actually this would be useable with a poiner container (eg. http://www.boost.org/doc/libs/1_39_0/libs/ptr_container/doc/ptr_container.html [^]). But since pointer containers are not yet standardised, I think it's better just not to mention it and remove the paragraph]

(0008730)
JesÃºs DomÃnguez
08-06-2009 13:54

After discussion on the phone with Anthony we understand the following things were agreed:
- method "isEmpty" should be renamed to "empty"
- method "getComponents" should be removed
- method "get" to be changed to return a pointer (to use NULL if "p_index" is out of bounds)
virtual const TciModuleId *get (Tsize p_index) const =0;
- method "add" to be renamed to "push_back"
- method "equals" to be substituted with operator "=="
virtual Tboolean operator== (const TciModuleIdList &midList) const =0;
- method "cloneXXX" to be renamed to "clone"
- section 10.5 to be changed to give a better explanation
About the begin,end methods we don't agree with adding them. It was mentioned with the getComponents method that we should not add design constraints. But if we add the "begin","end" or more C++ standard library methods we will obly to implement them (they are pure virtual), making them exactly like the STL containers. Wouldn't it be easier in that case to make directly a typedef to an STL class?

(0008738)
Anthony Baire
10-06-2009 18:44

Hi Jesus,
defining some iterators is not a design constraint is the sense that it does not dictate the internal structure of the class.
For example to implement TciModuleIdList a developper will have to represent internally this module list. There are lots of different ways he may want to do that (depending on the internal design of his runtime system) for example:
* by storing references to a TciModuleId base object
std::vector<TciModuleId*> mModuleIdList; // -> using a STL vector of pointers
boost::ptr_vector<TciModuleId> mModuleIdList; // -> using a pointer container
* by storing objects inherited from TciModuleId (eg. MyModuleId)
std::vector<MyModuleId> mModuleIdList // -> using a STL vector of MyModuleId
std::vector<MyModuleId*> mModuleIdList; // -> using a STL vector of pointers
boost::ptr_vector<MyModuleId> mModuleIdList; // -> using a pointer container
* also if he's concerned by the execution speed, he may want no to use the default allocator so as to optimise memory allocations
std::vector<MyModuleId, boost::fast_pool_allocator<MyModuleId> > mModuleIdList;
This is the reason why the getComponent() function is a strong design constraint, because it forces the developer to store the list as a std::vector<TciModuleId*>
By opposition the iterators can be flexibly defined regardless the internal design of the class, and they don't introduce any overhead in the execution.

(0008770)
Raul Alfonso
15-06-2009 14:15

Hi Anthony,
getComponents() or iterators (begin & end) isnâ€™t the issue. Weâ€™re agreed with you about design restrictions in getComponents methods and defining some iterators isnâ€™t a design restriction, but we arenâ€™t agreed with you about add iterators (and begin and end methods) to the interface. Why? If these methods are included we are forcing to implement them and we think that the tci-inteface should only have methods to use in tci context, not in other context (stl algorithms). We use these objects with stl algorithms, but other implementations of these interfaces may not use the stl algorithms. We think that we shouldnâ€™t force to someone to implement this methods.

(0008847)
Anthony Baire
06-07-2009 15:48

getComponents() puts a constraint on the internal design of the class: this affects the operation of the class as a whole. Adding iterators does not affect the internal design of the class but only its interfaces: other operations are not affected. Anyway, just removing getComponents() and not adding the iterators is an acceptable solution for us.