Changes in the C++ API interfaces

[spoirier]

Hi all,

I've committed some major changes in the core API interface
At NOBUGS, we agreed (David, Eugen, and I) on the fact that the core API have to propose pure abstracts interfaces and impose no dependencies on thirdparty libraries (YAT).

The following classes are now part of the implementation and should not be included by a client code :
View, Array, Key, LogicalGroup,

They are replaced, on the client side, by these interfaces:
IView, IArray, IKey, ILogicalGroup

The core Factory object is now a front end to its implementation FactoryImpl

Having pure abstracts interface unfortunately involves the loss of some (not vital) functionalities:
Because templates can't be virtual, the client code have to define CDMA_NO_TEMPLATES in order to get only pure abstract interfaces.
It will loose convenient data access methods and will have to deal with void* pointers on array data.
Also the iterator objects family (ArrayIterator, Slicer) can't be abstracted because the ++/--/==/!= operators can't be virtual. It will hidden if CDMA_NO_ITERATORS is defined by the client code

I tried to remove all dependencies to the YAT library. I successfully removed all dependencies except for the shared pointers.
Actually the only way to get ride of the yat::SharedPtr is to use a compiler that support the std::shared_ptr class.
This class is available on the latest MSVC product, if I understood correctly.
So the header file Common.h now contains a automatic switch based on compiler version standard library versions.
Depending of the result of this test the core library will uses the std::shared_ptr or the yat::SharedPtr.
I didn't try it a Windows, David can you have a look on it ?

I have adapted (and committed) the source code of the nexus engine and both nexus plugins

I'm now waiting for your comments...

Regards

Stephane

[spoirier]

Hi David,

Thanks you for your quick reply :)

Here is my responses to your comments and questions

De : MANNICKE, David
Date d'envoi : mercredi 24 octobre 2012 08:05
À : POIRIER Stephane
Objet : RE: Changes in the C++ API interfaces [SEC=UNCLASSIFIED]Hello Stephane,

 

I went through the modified header files and I really like the modifications you made!

 

Here are some comments and questions (in no particular order):

 

 

In regards to interfaces and iterators (ArrayIterator and SliceIterator), what do you think about using an interface which supports following methods:

 

Next()/Before() or Advance()/Recede() as well as bool Equal(other) and int Compare(other)

Yes it's a possibility => perhaps for version 4.

 

 

In the header IArray.h for example you used the following syntax:

 

getSlicer(int rank) throw (cdma::Exception)

 

In the recent C++ language standard (C++11), the use of exception specifications as specified in the preceding version of the standard (C++03) is deprecated. However, if one wants to specify that a function will never through an exception then the noexcept keyword should be used.

If Eugen agree with you I'm ok with you for removing all the throw (cdma::Exception) statements, if it's what you mean.

 

Just personal curiosity, why did you use the following programming style:

 

private:

  IArray() {}

public:

  friend class Array;

 

Why did you not use the following?

 

protected:

  IArray() {}

 
It's just for specify the fact that those interfaces can't re-implemented on client side.

 

ILogicalGroup depends on IContainer which in turn depends on AttributeList which is not an interface. Is that intended?

Where did you see that ILogicalGroup depends on IContainer  ?? IGroup does, in the current version, but IContainer no longer depends on AttributeList. (perhaps I didn't understood your remark...)

 

 

Does the header IContainer.h need #include <cdma/array/impl/Range.h>?

IContainer should not depends of Range.h. I will fix this!

 

 

Does the header IKey.h need #include <cdma/dictionary/plugin/PluginMethods.h>?

Same as previous remark. I will fix this too

 

 

Why do interface-headers currently include exception headers?

Ok I will check and remove the inclusion if it's not necessary (no 'throw ( cdma::Exception)' statement in method declarations).

 

 

Please let me know if my comments and questions don’t make any sense. I am looking forward to hear back from you.

Of course all your comments and questions are make sense David ;-)

 

Thank you for your effort!

 

Best regards,

David

 

[Eugen Wintersberger]

Hi folks
sorry for my late reply. I was pretty busy with other things here at
DESY. I am actually downloading the svn repository in my box here at
home. I hope that I will have some time during the weekend to go through
the code and give some comments.

Concerning virtual member functions I am actually have similar problems
and try to find out if one can use type erasures to fix this problem.

@Stephane: is the roadmap for CDMA somewhere available on the web? I
forgot the milestones ;)

regards
Eugen

> --
>
>
>

[Eugen Wintersberger]

Ok. I am actually trying to get the build with scons running. It seems
that there are a lot of header files still including yat. Have you
commited your changes already to the trunk?

regards
Eugen

> --
>
>
>

[spoirier]

Hi Eugen,

All the changes are already committed in the trunk.
Header files that still include some yat objects are (supposed to be) only in the "impl" subdirectories, only needed by the core library. YAT is always needed for the core, but not for client applications. I known I know there still some things to clean up  (see my response to David).

regards

Stephane

[spoirier]

Le vendredi 26 octobre 2012 21:58:10 UTC+2, Eugen Wintersberger a écrit :

Hi folks
  sorry for my late reply. I was pretty busy with other things here at
DESY. I am actually downloading the svn repository in my box here at
home. I hope that I will have some time during the weekend to go through
the code and give some comments.

No problem. I'm also pretty busy with internal projects!
 

Concerning virtual member functions I am actually have similar problems
and try to find out if one can use type erasures to fix this problem.

You are free to propose a solution to fix this :)
 

@Stephane: is the roadmap for CDMA somewhere available on the web? I
forgot the milestones ;)

The roadmap in not yet on the wiki, I know I have to publish it asap

 
stephane