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

[Gotthard,Petr]

BTW, have you seen this?
http://www.bearcave.com/software/c++_mem.html

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Gotthard,Petr
Sent: Friday, June 13, 2008 4:47 PM
To: CERTI development discussions
Subject: RE: [certi-dev] Request for comments: IEEE 1516.2 compliant
encoding

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


--
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel