Hi Vitaliy,
I sort of can see it now, you do not create the infrastructure at all,
you just create a sort of OOP by keeping to a consistent name
convention.
You use the struct but you can get away without using it at all. If you
called the "field" PacketHandler_fieldName it would do the same job.
When I looked at those two articles I thought that you were building an
infrastructure for object instantiation, but really you are sort of
using the class in a static way.
I will try this method as it will be easier to implement with my
compiler than the other. I will still try the other method as it seems
interesting.

Thank you very much for your and others help.

Best Regards
		Luis  



-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf
Of Vitaliy
Sent: 11 July 2009 04:03
To: Microcontroller discussion list - Public.
Subject: Re: [EE] OOP in C on PICs

Luis Moreira wrote:
> I apologise for not posting anything yet about this subject, but I am
> trying to process all the information about it.

No problem at all.


> The problem I have at the moment is that I just discovered that the
CSS
> C compiler does not deal very well with function pointers especially
in
> structs, hence is delaying my research into the subject.
>
> The first issue I had to overcome was the fact that I am not only
> writing a program using OOP I am also writing the infrastructure to
> generate the objects and actually that is the most important part. I
> will also start by not having inheritance but I can see how that could
> be done. The other issue I had is the "VTable" I could not understand
> its function.

As I've mentioned several times before, we are not using virtual
functions. 
I think the benefit you get, does not warrant the extra overhead and 
complexity.

Let me make this clear: we DO NOT have the infrastructure to create
objects. 
We create "data-only" objects dynamically when it is warranted, but they

don't have pointers to functions, they're just data (structures).
Functions 
are the normal, static C functions that manipulate the data.


> So this is how I am doing it:
>
> I have a function called checksumCalculator() which takes two
parameter,
> an int bufferSize and an array of chars buffer which is the packet. It
> returns a char checksumCal which represents the checksum.

A noun is a bad name for a function. A better name would be something
like:

    PacketHandler_CalculateChecksum(int bufferSize, char *buffer)


> To transform it into a class I created three, setSize, setBuffer,
> calculatechecksum. I also have three fields, bufferSize, buffer and
> checksumCal.
>
> So far all seems ok, but then what I envisage is a struct with the
three
> fields and three function pointers one for each of the methods. When
an
> instance of the class is created the three fields are initialised and
> the function address passed to the pointers. Is this what you do?

Not at all. We do not instantiate objects. I described what we do in
other 
posts, it is fairly simple, which leads me to believe that you are 
overthinking it.

In your case, the object would be:

- A file called PacketHandler.c, which contains public and private
functions
- A file that exports public functions and data, PacketHandler.h
- A structure of type TPacket, that has the members size, buffer, and 
checksum:

typedef struct
{
    int size;
    char *buffer;
    char checksum;
} TPacket;

You can then either declare your rxPacket and txPacket statically, or
create 
them dynamically (using calloc()) at runtime.


> I found that when I try this I can not manipulate the fields of the
> struct with the class methods, how did you get around that?

We sidestep the issue by avoiding having virtual functions. :-)


> I am probably making a mess out of this, so apologies in advance.

No need to apologize. The setup that we have now, is the result of many 
months of trial and error. We followed many many blind alleys until the 
whole picture finally emerged. And we're still making improvements as we
go.

I just hope I can help save you some grief.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist