Re: [certi-dev] Request for comments: IEEE 1516.2 compliant encoding

[Eric Noulard]

2008/6/8 Gotthard,Petr <address@hidden>:
> Hi everybody,
> I've made an attempt to implement encoding functions that support
> datatypes defined in IEEE 1516.2
> http://savannah.nongnu.org/patch/?6534
>
> I would appreciate a feedback from you, particularly regarding the
> following issues:
>
> (1) user friendliness
> There is a test application (encod.cpp) that shows how the templates can
> be used. Any suggestions to be yet more user friendly?

This looks good.
Template declaration may becomes awkward fro HLAxxxxRecord
if you ever want to have nested HLAxxxRecord within HLAxxxRecord.

If the record do only contains basic types you'll get 1 template
level for each field so the last line may be:

HLAfixedRecordEnd >>>>>>>>>>>>>>>>>>>>>>>>>> yourType;

This is not that bad but....

I would rather write

TB B;

than

TB& B = (TB&)*buffer;

but keep reading

> (2) efficiency vs. C++ compiler compatibility
> To achieve the highest efficiency I used a template metaprogramming

This is nice.

> and one extraordinary trick (static_cast of the "this" pointer). After
> thinking a lot I believe this trick is correct and does not break
> portability to other C++ compilers. Any thoughts?

My personal thought is that you are not allowed to do that,
or I need explanation why :=)
"this" pointer is not meant to be a lvalue, it may be returned but I
wouldn't play
with "this" pointer assignement nor cast.
I no standard C++ at hand but I would bet that "this" pointer is read-only area.

What is the problem with embedding a field of type "T" inside struct
HLAbasicType?

You cast-this trick "may" be working because:
 - your structure does not have any embedded field
 - you do not use inheritance, which is OK
   but if a user is trying to do
          class myType : public HLAinteger32BE
   it will probably break sooner or later

 - you rely on the user to provide you with a memory buffer of the
appropriate size
   and I personnally find it risky. What do you think of
       buffer = malloc(1);
       TB& B = (TB&)*buffer;
       B[0].field<FIELD_B>() = '0';
       B[1].field<FIELD_A>() = 42;

Finally I think the template usage is just neat, but I would like to ensure
that memory usage will be controlled.
There should be a way to automatically allocate needed memory from
within the template
and not requiring the user to provide a buffer.
If you want to keep the buffer way you, I think you need to make default
constructor private (even struct have a constructor), because currently:
       TB B;
       B[0].field<FIELD_B>() = '0';
       B[1].field<FIELD_A>() = 42;
will compile fine, but break surely.

If you like the idea of the user-allocated memory then I'd rather go with
something like:

TB B(buffer, bufferSize);


> I've tested my implementation under Linux/GCC and Windows/MSVC. What
> else do you use?

    Same for me, but running the program and seing the appropriate result
    does not mean you have the right to do what you do :-), no offense though.
    Template machinery and trickery usage begans with people using compiler
    construct they were not expected to use in the first place
http://ubiety.uwaterloo.ca/~tveldhui/papers/Template-Metaprograms/meta-art.html
http://ubiety.uwaterloo.ca/~tveldhui/papers/priority.html#tmp
    so may be you are plain right....

> (3) CVS repository
> Where would you store it? It's not application-specific (so it's not
> good to stored it in address@hidden) and it's not a standartized
> HLA API (so it's not good to store it directly in CERTI).

We have opened "HLA-related" module at CERTI repository:
http://cvs.savannah.gnu.org/viewvc/applications/?root=certi
we may open a new one.

however I think the work deserve to be shipped along with CERTI.
CERTI already contains lib/header which are HLA standardized
(libRTI, RTI.hh  etc...)
and CERTI specific part like "libCERTI"
we may create something like "libHLA" which may contain HLA-related
code (header or lib, or tools) which may be of general interest for
HLA (not only CERTI) user.

This could be
1) a standalone module which could be hosted in the certi CVS for
    convenience
    CVSROOT/applications/libHLA

2) or a CERTI submodule

    CVSROOT/certi/libHLA

3) or you may create a standalone project
     which may be linked with VirtualAir, CERTI, etc....

-- 
Erk