Luis Moreira wrote:
> 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.

In a nutshell, yes. It is more complicated than just following a naming 
convention for functions and data, but the point is that we don't do it in 
two steps: 1) create the object-creating infrastructure and 2) write app 
code. We follow the OOP rules _while_ writing the application code.


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

Mmm.. no.  :)

It is a little difficult to explain the reasons why it wouldn't work without 
an actual example, but if you tried it you would quickly discover them 
yourself.

The first problem is that you could not declare a variable of type TPacket. 
You couldn't just say:

    TPacket rxPacket;
    TPacket txPacket;

or maybe even

    TPacket tenPackets[10];

The second problem is that now when you make a function call to send a 
packet, instead of providing just one argument (a pointer to your packet 
structure):

    PacketHandler_SendPacket(txPacket);

you have to list all arguments:

    PacketHandler_SendPacket(txPacket_bufLen, txPacket_buf, 
txPacket_checksum);

Doing it the second way also makes the code tightly coupled (=bad). Say you 
need another attribute, "priority". With the first way, you only need to 
change the code in two places: add a member to the TPacket structure, and 
add code to the SendPacket function to do something with this new member. 
The second way would force you to change the calls to SendPacket() as well.

    PacketHandler_SendPacket(txPacket_bufLen, txPacket_buf, 
txPacket_checksum, txPacket_priority);

Using a structure to encapsulate the attributes makes the code a lot more 
readable, with little additional effort and code overhead.


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

Yes, sort of. The methods are static, but sometimes you dynamically create 
the data.


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

Once you try the other method, please let me know how you like it. There are 
several things about OOP that I miss occasionally, especially polymorphism 
and method overloading, but we have been able to find reasonable workarounds 
and like I said we didn't think the additional overhead (on the programmer 
side) was worth it.

Vitaliy

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