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

[Gotthard,Petr]

Hi Eric,
thank you very much for your comments.

> 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....

Yes, it's a bit ugly, but it's the only way (I found) to make a
template-based list of entries of different types.

> 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.

I don't change "this" pointer. Please, open your mind and follow my
thoughts:

If you have struct { int A; } S, you can take a buffer, re-cast it to
this struct and then access it e.g. ((S*)buf)->A = 7. This is very
common e.g. when using inet_sockaddr.

If this struct has a function, you can use this->A = 7. You cannot
change "this" (and I don't do that), but you can change the object
pointed by "this" (this->A = 7).

Having two struct(S) one after another I can access the second one using
S+1, or (S*)(buffer+sizeof(S)). If this struct has a function, then this
becomes (S*)(this+sizeof(S)). And *this* is what my templates are doing.
Again, I don't change "this", I build a pointer to *another* struct.

The only assumption I made is that there are *no* foreign (e.g.
compiler-generated) data in the heap memory allocated for a given
struct. And I believe there *cannot* be any compiler-specific data
(besides padding) because then inet_sockaddr wouldn't work.
Static data are stored in a different memory segment and local variables
are stored on the stack. What else could be on the heap?

> 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

Right. These are the preconditions. You *must not* have any non-static
data and you *must not* use inheritance. That's the penalty for
performance.

>  - 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;

Right. The buffer overflow is not checked. It's similar to C++ arrays.
One reason is to have the highest efficiency (as you wanted ;-)), second
reson is that the allocated memory size is not known to the access
functions. There must be no non-static data, so I cannot store this
information anywhere.

> 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)

Good point. Constructors should be private.

> 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);

The memory cannot be allocated in the constructor. This would mean you
allocate a TB object on stack and this object then allocates something
on the heap. I cannot use stack, so I must use malloc/free directly.
However, I just found that new/delete operators can be overloaded. I'll
try to make use of them.

> > 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-a
rt.html
> http://ubiety.uwaterloo.ca/~tveldhui/papers/priority.html#tmp
>     so may be you are plain right....

Well, I think that I have the right to do everything what gives the
appropriate results. The only problem is that the trick is in a "grey
area" and I cannot 100% rule out getting inappropriate results on some
compilers.

> > (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.

OK


Best Regards,
Petr