Tom=E1s =D3 h=C9ilidhe wrote:
>> The object/method paradigm can be simulated as:
>>
>>     ObjectName_MethodName()
>>
>
> Do you mean ClassName instead of ObjectName?

It's a moot point.


> When I started out learning about classes in C++, learning about
> inheritance, polymorphism, all that stuff, I didn't like the explanation
> that it "just works", so I decided to take some object-orientated C++
> code and re-write it as C code, but with the aim of coming out with much
> the same machine code.

I think this kind of attitude is great for learning. However, eventually =

most programmers realize that they're more productive when they use the =

largest building blocks available, and treat them as black boxes.


[snip]
> Anyway the point of me getting into all this is to show that all that
> fancy object-orientated stuff in C++ isn't that magical at all, and in
> some places it amounts to nothing more than "syntactical sugar".

I'm with Tamas on this one. You could code everything in binary, but that =

would not be the most efficient use of your time. By letting the compiler, =

linker, and assembler do their job, you can concentrate on the design of =

your program. The rule of thumb is, use the highest level level language =

available for the platform.


[snip]
> I wouldn't bother putting some sort of "private indicator" on them. I'd
> just define them as "static" in the source file and put no declaration
> in the header file. Other translation units will never see them. The
> situation isn't much different in C++; you just write "private" in front
> of it instead of "static".

The purpose of the underscores is to visually distinguish private functions =

from other types of functions. They are for the benefit of the human readin=
g =

the code.


>> Has anyone else used anything similar in the past? I'd love to hear about
>> your experience.
>
> I started out programming in C++ before I started in C, so I was started
> out on the bandwagon of "macroes are evil, use functions instead". I
> went along this road for about five years maybe. The only time I would
> opt to make a macro instead of a function was when I needed it to
> evaluate to a compile-time constant. If this wasn't a requirement
> though, I went with functions.

My question referred to the practice of using OOP techniques on projects =

written in C.


> When I got into embedded programming though, I found out that functions
> were the enemy. My original Connect4 game was too big to fit onto the
> PIC16F684. I went through it and replaced a load of functions with
> macroes, and then it fit snug.

Neither functions nor macros are the enemy. They're both just code. One is =

sometimes more appropriate than the other, but they both have their uses.

I prefer to write code in the most straightforward way first, then optimize =

the parts that require optimization.


> Unless you have a very good compiler that does justice to inline
> functions, then I'd shy away from making function for every little
> operation.

You can use functions or macros, the point is that you can take a cryptic =

statement such as:

    U1MODEbits.PDSEL =3D 0;

And convert it into this:

    Set8bitNoParity(&UartModeBits);

There are a number of advantages to this approach, including:

1. The function name tells you exactly what its purpose is.

2. Unlike comments, the function name does not easily get out of sync with =

what the code actually does.

3. It avoids duplication of code, enfocing the "one rule, one place" =

concept.

4. It helps promote tight cohesion.


So far, I haven't seen the need to fully implement C++ features like =

inheritance, in C. The effort involved in building the framework, adding =

objects, and maintaining the code is substantial, and the benefits are few. =

The downside is that the code becomes less readable, and more dangerous.

IMO, there are easier ways to achieve the same aims, without the overhead.


Best regards,

Vitaliy


-- =

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