The OPAL Discussion Forum

[Yves Ineichen <iff AT yvesineichen.com>]

Hi all,

Pointer ownership semantics: Another good practice is to set a
deleted pointer to 0 and always initialize pointers. Please also make
sure to write correct destructors [1].
On the long run I would strongly advocate the use of a smart pointer
framework. Boost smart pointers [2] would be a good candidate. Clearly
this would trigger a tedious and time consuming rewrite and
additionally increase the library dependencies of OPAL but most
probably it would be worth the time.


Concerning coding style: we have an astyle [3] configuration available
[4] that defines some of the most important style guidelines, mostly
concerning code formatting to have a "uniform code representation". In
order to be able to use [4] the astyle binary has to be downloaded or
built. If requested we can upload a modified svn commit (or git
pre-commit hooks) that automatically reformats changed code before
committing.


Regards,

[1] http://www.parashift.com/c++-faq-lite/dtors.html
[2] http://www.boost.org/doc/libs/1_47_0/libs/smart_ptr/smart_ptr.htm
[3] http://astyle.sourceforge.net/
[4] http://amas.web.psi.ch/tools/OPAL/opal_cleanup.astyle



On Wed, Aug 24, 2011 at 10:47 AM, Andreas Adelmann
<andreas.adelmann AT psi.ch> wrote:
> Dear Colleagues I would like to start a discussion on policies for the
> future  OPAL development. Please contribute.
>
> H5 Error Handling Policy in OPAL
> ===========================
>    h5_int64_t rc;
>
>
>
>    rc = H5WriteFileAttribInt64(H5file_m, "nAutoPhaseCavities",
> &nAutopPhaseCavities, 1);
>
>
>    if(rc != H5_SUCCESS)
>
>       ERRORMSG("H5 rc= " << rc << " in " << __FILE__ << " @ line " <<
> __LINE__ << endl);
> If for example core 2 has a problem, you will be notified like this:
> Error{+2}> H5 rc= -3 in
> /gpfs/homefelsim/adelmann/svnwork/OPAL/src/Structure/DataSink.cpp @ line 499
> With the OPAL argument --error=0 you can disable all ERRORMSG's.
>
>
> Memory Handling Policy in OPAL
> ===========================
> Basic principe, every class has to cleanup the allocated memory, either
> immediately in the method or in the destructor.
> However there are some exceptions (DataSink and PartBunch). Also the
> references in the global object OpalData
> poses some problems (check out Main.cc ab the end of the file delete
> OPAL.getDataSink();)
> Here we need a redesign in the near future.
>
> Exception Handling Policy in OPAL
> ============================
> t.b.d
>
> Coding Style Policy in OPAL
> =======================
> t.b.d
>
>
>
> Best Andreas
> ------
> Dr. sc. math. Andreas (Andy) Adelmann
> Staff Scientist
> Paul Scherrer Institut WLGB/132 CH-5232 Villigen PSI
> Phone Office: xx41 56 310 42 33 Fax: xx41 56 310 31 91
> Phone Home: xx41 62 891 91 44
> -------------------------------------------------------
> Friday: ETH CAB H 83.1  +41 44 632 36 72
> ============================================
> The more exotic, the more abstract the knowledge,
> the more profound will be its consequences.
> Leon Lederman
> ============================================
>
>
>



-- 
Yves Ineichen
::p = "This statement cannot be proven"::