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

[Eric Noulard]

2008/6/13 Gotthard,Petr <address@hidden>:
> Hi Eric,
> thank you very much for your comments.

you're welcome :=)

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

Yes I agree, and I think you should make this explicit by calling

reinterpret_cast<S*>(buf)->A = 7

see for example:
http://www.cplusplus.com/doc/tutorial/typecasting.html

[...]

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

That's right you should be right.

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

When using template you should be able to buy both performance and inheritance,
but that's not the point here, I'll try to give an example.

> Right. The buffer overflow is not checked. It's similar to C++ arrays.
> One reason is to have the highest efficiency (as you wanted ;-)),

I do :=)

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

You are storing the information in this using operator =.

  HLAbasicType& operator = (const T& data)
  {
    *(T*)this = E<T,S>()(data);
    return *this;
  }

My idea was to use a pointer field which may be different from this,
but that can be initialized in the only constructor at user disposal:


> Good point. Constructors should be private.
>
>>
>> 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.

I won't allocate anything in this constructor but only doing something like:

this->buffer = buffer
STATICALLY_CHECK_BUFFER_SIZE_IS_OK(bufferSize)

> This would mean you
> allocate a TB object on stack and this object then allocates something
> on the heap.

TB object is on stack and is "shallowing" heap allocated memory
provided by "buffer".
The difficult part is to STATICALLY_CHECK_BUFFER_SIZE_IS_OK(bufferSize)
may be with template programming (using the S'ize' template param)

> However, I just found that new/delete operators can be overloaded. I'll
> try to make use of them.

overloading operator new is somehow syntactic sugar
using the same idea as:

TB B(buffer, bufferSize);

but it may be nice to write

TB* B = new(buffer) TB();


-- 
Erk