Searching \ for '[EE] Implementing OOP features in C' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=c
Search entire site for: 'Implementing OOP features in C'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Implementing OOP features in C'
2008\07\04@024159 by Vitaliy

flavicon
face
Mark Rages wrote:
{Quote hidden}

This is an update, since I promised to "reply in a few days" :)

After reading the suggested articles and doing some coding, I decided that
for now, implementing inheritance in C is not worth the trouble for me. And
that's fine, so far I haven't really needed to use inheritance -- and this
fits well with the Design Patterns principle "favor aggregation over
inheritance".

I am "simulating" certain OOP concepts and find them to be very useful. For
example, I put only closely related data and functions in one module, which
is named after the "object" ("something with responsibilities"). Data is
accessible using accessor methods. The result is tight cohesion and loose
coupling.

The object/method paradigm can be simulated as:

   ObjectName_MethodName()

The method declaration gets put in the .h file. The big advantage of this
naming convention, is that it answers the question "which file has the
definition of this function"? It also tells the reader that it's a "public"
function, exposed through the module's interface (.h file).

Private functions are named using the format:

   __FunctionName()

per Miro's suggestion. Turns out, it's a good idea to use them to
encapsulate even the small operations, like setting or clearing a byte. This
may sound ridiculous, but the big advantage is that you essentially put the
comments (what the function does) into the function name. It drastically
improves readability, and the comments never get out of date or out of sync.

Has anyone else used anything similar in the past? I'd love to hear about
your experience.

Vitaliy

2008\07\04@041756 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
{Quote hidden}

byte.

AFAIK symbols with a leading underscore (or two) are reserved for use by
the compiler implementer, and should not be used in your own own code.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\07\04@042615 by Alan B. Pearce

face picon face
>I am "simulating" certain OOP concepts and find them to be very useful.
>For example, I put only closely related data and functions in one module,
>which is named after the "object" ("something with responsibilities").
>Data is accessible using accessor methods. The result is tight cohesion
>and loose coupling.

Ah, just like using linkable assembly ...

One of the things I learnt from using Olins environment. ;)

2008\07\04@045416 by Vitaliy

flavicon
face
Michael Rigby-Jones wrote:
>> Private functions are named using the format:
>>
>>     __FunctionName()
>>
>> per Miro's suggestion. Turns out, it's a good idea to use them to
>> encapsulate even the small operations, like setting or clearing a
> byte.
>
> AFAIK symbols with a leading underscore (or two) are reserved for use by
> the compiler implementer, and should not be used in your own own code.

Initially I was concerned about that too (I remembered seeng similar
"reserved" functions in a Microsoft QuickC manual). However, the Miro guy
suggested the idea (he sounds like he knows what he's talking about), and
the article was printed in a respectable industry publication. I think
symbols with a leading underscore are a problem only when they happen to
coincide with names reserved by the compiler.

Vitaliy

2008\07\04@072634 by olin piclist

face picon face
Vitaliy wrote:
> I think symbols with a leading underscore are a problem
> only when they happen to coincide with names reserved by the compiler.

Exactly.  You are in the namespace reserved for compilers.  You will
probably get away with it most of the time, but the one time you don't could
be a major pain to diagnose.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\04@072958 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On
Behalf
{Quote hidden}

use by
> > the compiler implementer, and should not be used in your own own
code.
>
> Initially I was concerned about that too (I remembered seeng similar
> "reserved" functions in a Microsoft QuickC manual). However, the Miro
guy
> suggested the idea (he sounds like he knows what he's talking about),
and
> the article was printed in a respectable industry publication. I think
> symbols with a leading underscore are a problem only when they happen
to
> coincide with names reserved by the compiler.

Vitaliy,

You are correct; they won't cause problems until you unknowingly define
a symbol that the compiler uses (or the next compiler that someone may
use).  Using the compilers namespace like this is bad practice, but and
is often propagated by people who look through the compilers header
files and copy the style, not knowing any better. I am guilty of this, a
lot of the code I wrote many years ago has include guards that start
with a leading underscore, which I remove if I have to make any
revisions.

Unfortunately even if a publication has a respectable image, that
doesn't stop them publishing the odd bit of incorrect or misleading
information.

Since the format of the function name is not critical, you could simply
append a single character to the start and totally avoid any potential
issues.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\07\04@081448 by Tomás Ó hÉilidhe

picon face

> The object/method paradigm can be simulated as:
>
>     ObjectName_MethodName()
>  

Do you mean ClassName instead of ObjectName?

> The method declaration gets put in the .h file. The big advantage of this
> naming convention, is that it answers the question "which file has the
> definition of this function"? It also tells the reader that it's a "public"
> function, exposed through the module's interface (.h file).
>  

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.

So for a normal non-virtual function, instead of having the following in
C++:
   name_of_object.SomeMemberFunction(5);

I would have the following in C:
   NameOfClass_SomeMemberFunction(&name_of_object,5);

As you can see, the C function takes a pointer to the object as its
first parameter. This is how C++ compilers do it, they have a hidden
parameter at the beginning which is the "this" pointer.

When it came to implementing polymorphism, I did it exactly the same way
that C++ compilers do, i.e. using a V-Table. So if you had the following
in C++:

   class 3D_Shape {
   public:
       virtual double GetVolume(void) const;
   };

Then in C it would be:

   struct 3D_Shape;  /* Forward declaration */

   struct VTable_3D_Shape {
       double (*GetVolume)(struct 3D_Shape const *);
   };

   typedef struct 3D_Shape {
       VTable_3D_Shape const *pvtable;
   } 3D_Shape;

And so then you'd have the following C code:

   3D_Shape my_shape;

   3D_Shape_Constructor(&my_shape);  /* If there's a constructor */

   my_shape.pvtable->GetVolume(&my_shape);

If you don't like the above line, you could make a wrapper macro or
wrapper function that turns it into:

   3D_Shape_GetVolume(&my_shape);

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".
Contrast the following two code snippets for instance:

   MyClass my_object;
   my_object.DoSomething(5,3,2);

and:

   MyClass my_object;
   MyClass_Constructor(&my_object);
   MyClass_DoSomething(&my_object,5,3,2);
   MyClass_Destructor(&my_object);

Sure, it's handy that the constructor and destructor get called
automagically, but the actual member function call is nothing special --
it's just a different syntax. Taking some example object-orientated C++
code and converting it to C code can be quite easy if you get a little
practise... although admittedly things get a little hairy when you get
into multiple virtual inheritance.

> Private functions are named using the format:
>
>     __FunctionName()
>
> per Miro's suggestion.


I don't know if you're into writing standard-compliant code, but I'd
double check the Standard before I use double underscores at the start
of a function name. There's some stuff like that that's reserved for the
compiler's implementation. I don't it off by heart but double
underscores is ringing a few bells.

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

>  Turns out, it's a good idea to use them to
> encapsulate even the small operations, like setting or clearing a byte. This
> may sound ridiculous, but the big advantage is that you essentially put the
> comments (what the function does) into the function name. It drastically
> improves readability, and the comments never get out of date or out of sync.
>
> 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.

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.

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.

2008\07\04@084928 by Tamas Rudnai

face picon face
> 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".

You could say that to all formal languages... C is just a fancy stuff over
Assembly, Assembly is just a fancy stuff over object code, object
codes/linkers are just fancy stuff over HEX files... and HEX files are just
fancy stuff over 0 and 1...

I think there are quite a few people here who wrote or who are still in
development of a compiler. Probably they could explain better of usage of
functions, instinct functions, macros and templates why and when it is
supposed to use. I do not believe of evil and god language elements (or
languages either - except Basic of course which is Evil for sure :-)
_just_kidding_). Computers and microcontrollers are not Earth or Heaven -
sometimes are Hell though :-), but only if you have a religious mind of
programming and believe in all of the Silicon Gods.

Tamas


On Fri, Jul 4, 2008 at 1:14 PM, Tomás Ó hÉilidhe <EraseMEtoespam_OUTspamTakeThisOuTlavabit.com> wrote:

{Quote hidden}

>

2008\07\04@102938 by olin piclist

face picon face
Tamas Rudnai wrote:
> I do not believe of evil and god language
> elements (or languages either - except Basic of course which is Evil
> for sure :-) _just_kidding_). Computers and microcontrollers are not
> Earth or Heaven - sometimes are Hell though :-), but only if you have
> a religious mind of programming and believe in all of the Silicon
> Gods.

You only need to believe in the dead fish.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\04@123549 by Peter Todd

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 04, 2008 at 07:28:39AM -0400, Olin Lathrop wrote:
> Vitaliy wrote:
> > I think symbols with a leading underscore are a problem
> > only when they happen to coincide with names reserved by the compiler.
>
> Exactly.  You are in the namespace reserved for compilers.  You will
> probably get away with it most of the time, but the one time you don't could
> be a major pain to diagnose.

Or, if not to diagnose, to fix...

___foo isn't reserved however and is only a character longer.

Then, user extensions to your application can use ____foo :)

- --
http://petertodd.org 'peter'[:-1]@petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIbkxa3bMhDbI9xWQRAoRtAJ47RuhWRelF7LfskIn8BPIonO9VuQCgsI70
RBXQG7m8A5hUCtY1KTEEb20=
=BBvi
-----END PGP SIGNATURE-----

2008\07\04@144351 by Peter

picon face
> > a religious mind of programming and believe in all of the Silicon
> > Gods.
>
> You only need to believe in the dead fish.

The only provenly valid $deity in technical domains is Murphy's spirit.
Unfortunately. And he is more a relative of Loki than of Mother Theresa if you
see what I mean ...

Peter


2008\07\04@145027 by Peter

picon face
> > I think symbols with a leading underscore are a problem
> > only when they happen to coincide with names reserved by the compiler.
>
> Exactly.  You are in the namespace reserved for compilers.  You will
> probably get away with it most of the time, but the one time you don't could
> be a major pain to diagnose.

I was under the impression that the compiler or the preprocessor always adds
another underscore to avoid that ?

Peter


2008\07\04@153407 by Peter Todd

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jul 04, 2008 at 06:46:56PM +0000, Peter wrote:
> > > I think symbols with a leading underscore are a problem
> > > only when they happen to coincide with names reserved by the compiler.
> >
> > Exactly.  You are in the namespace reserved for compilers.  You will
> > probably get away with it most of the time, but the one time you don't could
> > be a major pain to diagnose.
>
> I was under the impression that the compiler or the preprocessor always adds
> another underscore to avoid that ?

No, the point of that namespace is for compiler to code communication.
For instance C++ compilers define __cplusplus leading to the following
fragment often seen in #include files:

#ifdef __cplusplus
extern "C" {
#endif

<stuff>

#ifdef __cplusplus
}
#endif

The point being if your code defines something starting with __, it may
collide with a compiler defined magic name.

- --
http://petertodd.org 'peter'[:-1]@petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIbnqs3bMhDbI9xWQRApx3AKCW8jtRDI7Dk2v+pNKSKqfyQcqiJgCgk/B2
xkPUF5fiHJ7wuzJ7iTNBh/Y=
=BNha
-----END PGP SIGNATURE-----

2008\07\04@165659 by Tomás Ó hÉilidhe

picon face

Peter Todd wrote:
> The point being if your code defines something starting with __, it may
> collide with a compiler defined magic name.

The main thing about it all is "defined behaviour" versus "undefined
behaviour". If you use double underscores in your own code then the
behaviour of the program is undefined by the C standard. That is to
say:  If your program doesn't work properly, the Standard doesn't care,
because it makes no guarantees if the behaviour is undefined.

So if you have a wild name such as:

   __BigMonkeyYellowDishwasherOvernightSkyResort

then a fully-compliant C standard compiler is within its rights to
produce a program that counts from 10 backwards and then formats your
hard disk.

Personally, I wouldn't use double underscores myself. You might come
across a compiler one day that kicks out an error:

   Line 17: ERROR : Token beginnings with double underscores are
reserved for the implementation

2008\07\04@184810 by William \Chops\ Westfield

face picon face

On Jul 4, 2008, at 4:28 AM, Olin Lathrop wrote:

>> I think symbols with a leading underscore are a problem
>> only when they happen to coincide with names reserved by the  
>> compiler.
>
> Exactly.  You are in the namespace reserved for compilers.  You will
> probably get away with it most of the time, but the one time you  
> don't could
> be a major pain to diagnose.

You will normally get errors (multiply defined symbols or type  
mismatch) from the linker.
The pre-defined symbols tend NOT to be things linked "on demand" from  
libaries, but things included explicitly and unconditionally.  For  
instance, a trivial unix C program run through "objdump -
t" (instructional to do in itself!) shows:

objdump -t a.out | grep __
080495e4 l     O .ctors 00000000              __CTOR_LIST__
080495ec l     O .dtors 00000000              __DTOR_LIST__
0804850c l     O .eh_frame      00000000              __EH_FRAME_BEGIN__
080495f4 l     O .jcr   00000000              __JCR_LIST__
08048314 l     F .text  00000000              __do_global_dtors_aux
080495e8 l     O .ctors 00000000              __CTOR_END__
080495f0 l     O .dtors 00000000              __DTOR_END__
0804850c l     O .eh_frame      00000000              __FRAME_END__
080495f4 l     O .jcr   00000000              __JCR_END__
080484b0 l     F .text  00000000              __do_global_ctors_aux
08049510 g       *ABS*  00000000              .hidden __fini_array_end
08049514 g     O .data  00000000              .hidden __dso_handle
0804846c g     F .text  00000044              __libc_csu_fini
08049510 g       *ABS*  00000000              .hidden __fini_array_start
08048424 g     F .text  00000048              __libc_csu_init
08049614 g       *ABS*  00000000              __bss_start
080482ac       F *UND*  000000de              
__libc_start_main@@GLIBC_2.0
08049510 g       *ABS*  00000000              .hidden __init_array_end
08049510 g       *ABS*  00000000              .hidden  
__preinit_array_end
08049510 g       *ABS*  00000000              .hidden __init_array_start
08049510 g       .data  00000000              __data_start
08049510 g       *ABS*  00000000              .hidden  
__preinit_array_start
00000000  w      *UND*  00000000              __gmon_start__

If I go and make __libc_csu_init a declared variable, I get:

gcc foo.c
/usr/bin/ld: Warning: size of symbol `__libc_csu_init' changed from 4  
in /tmp/cc49LflK.o to 72 in /usr/lib/libc_nonshared.a(elf-init.oS)
/usr/bin/ld: Warning: type of symbol `__libc_csu_init' changed from 1  
to 2 in /usr/lib/libc_nonshared.a(elf-init.oS)

Worth experimenting with, to better understand how your compiler  
behaves, IMO.

BillW

2008\07\06@170044 by Vitaliy

flavicon
face
Michael Rigby-Jones
> You are correct; they won't cause problems until you unknowingly define
> a symbol that the compiler uses (or the next compiler that someone may
> use).  Using the compilers namespace like this is bad practice, but and
> is often propagated by people who look through the compilers header
> files and copy the style, not knowing any better. I am guilty of this, a
> lot of the code I wrote many years ago has include guards that start
> with a leading underscore, which I remove if I have to make any
> revisions.
>
> Unfortunately even if a publication has a respectable image, that
> doesn't stop them publishing the odd bit of incorrect or misleading
> information.
>
> Since the format of the function name is not critical, you could simply
> append a single character to the start and totally avoid any potential
> issues.

What character would you recommend I use?


2008\07\06@170231 by Vitaliy

flavicon
face
Tomás Ó hÉilidhe wrote:
> So if you have a wild name such as:
>
>    __BigMonkeyYellowDishwasherOvernightSkyResort
>
> then a fully-compliant C standard compiler is within its rights to
> produce a program that counts from 10 backwards and then formats your
> hard disk.

I am tempted to ask, "what have you been smoking today?"  :)

2008\07\06@181242 by Vitaliy

flavicon
face
Tomás Ó hÉilidhe 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 reading
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 = 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

2008\07\06@182514 by Tomás Ó hÉilidhe

picon face


Vitaliy wrote:
> What character would you recommend I use?


Well as I've said already, I wouldn't bother with a tag, I'd just define
it as static in the source file and then neglect to put a declaration in
the header file.

Of course though, you can always do something like:

Private_Function1
P_Function1
pFunction1

2008\07\06@192839 by Jinx

face picon face
> > a fully-compliant C standard compiler is within its rights to produce
> > a program that counts from 10 backwards and then formats your
> > hard disk.
>
> I am tempted to ask, "what have you been smoking today?"  :)

I'd been thinking, hmmm, perhaps I'll stay away from C until minor
bugs like that are sorted out

Olin, your PIC development environment doesn't do that does it ?
Make the chip scuttle off like cockroach maybe ?

2008\07\06@195935 by Tomás Ó hÉilidhe

picon face


Jinx wrote:
> I'd been thinking, hmmm, perhaps I'll stay away from C until minor
> bugs like that are sorted out
>
> Olin, your PIC development environment doesn't do that does it ?
> Make the chip scuttle off like cockroach maybe ?

http://www.catb.org/jargon/html/N/nasal-demons.html

2008\07\07@071031 by Tomás Ó hÉilidhe

picon face


Vitaliy wrote:
>>>     ObjectName_MethodName()
>> Do you mean ClassName instead of ObjectName?
>>    
>
> It's a moot point.
>  

Moot? Really? A class is the actual type. An object is an instance of
the class. I hope you don't intermix the terms.


> My question referred to the practice of using OOP techniques on projects
> written in C.
>  

This part of it wasn't:

"Turns out, it's a good idea to use them to

encapsulate even the small operations, like setting or clearing a byte. This
may sound ridiculous, but the big advantage is that you essentially put the
comments (what the function does) into the function name. It drastically
improves readability, and the comments never get out of date or out of sync."

and that's what I was replying to.


> I prefer to write code in the most straightforward way first, then optimize
> the parts that require optimization.
>  

I prefer to not have to go over the code at the end. When I've got a
simple little function that gets called dozens of times, I know it's
best as a macro. Of course you could opt to make an inline function out
of it but then you're depending on the compiler's efficiency.

{Quote hidden}

I agree with all points, (except the last one because it's too
unintelligible and ambiguous for my liking). I was addressing the issue
of using a macro versus a function, not the issue of whether this should
be done at all. I do it all the time in fact, mostly via macroes. For
example:

#define PiezoOn()  ((void)RA7 = 1)

2008\07\07@075834 by Tomás Ó hÉilidhe

picon face

Tomás Ó hÉilidhe wrote:
> #define PiezoOn()  ((void)RA7 = 1)

#define PiezoOn()  ((void)(RA7 = 1))

2008\07\07@164337 by Vitaliy

flavicon
face
Tomás Ó hÉilidhe wrote:
>>>>     ObjectName_MethodName()
>>> Do you mean ClassName instead of ObjectName?
>>>
>>
>> It's a moot point.
>>
>
> Moot? Really? A class is the actual type. An object is an instance of
> the class. I hope you don't intermix the terms.

It's really neither (we're working in C, remember?). I prefer to call it an
"object" because I'm not using it to instantiate anything, I can't derive
anything from it -- but I am treating it as "something with
responsibilities". Or, if you like, "a collection of related functions and
data".

>> My question referred to the practice of using OOP techniques on projects
>> written in C.
>>
>
> This part of it wasn't:

It is silly to argue that you know better than me what I meant. My question
referred to the subject of the email, not the paragraph preceding it.

>> I prefer to write code in the most straightforward way first, then
>> optimize
>> the parts that require optimization.
>>
> I prefer to not have to go over the code at the end. When I've got a
> simple little function that gets called dozens of times, I know it's
> best as a macro. Of course you could opt to make an inline function out
> of it but then you're depending on the compiler's efficiency.

You can call it a matter of taste.

The books I've read ("Code Complete" comes to mind), and personal experience
tell me it's better to "go over the code at the end". Optimizing parts that
are a not the bottlenecks is a waste of time, and since usually there is a
tradeoff (readability vs performance) it makes using and maintaining the
code more difficult than necessary. In the particular case we're discussing
(using macros or functions to encapsulate one-liners), this is largely
irrelevant.

>> 4. It helps promote tight cohesion.
>>
> I agree with all points, (except the last one because it's too
> unintelligible and ambiguous for my liking).

When I read some of your comments, I find myself thinking that perhaps
you're a troll sent by Olin to prove his point that newbies need to be
publicly embarrassed to teach them a lesson. :)

You're either a troll or a very thick-skinned newbie, so I will take the
bait and say that I would at least do a bit of research, before proudly
announcing my ignorance to the world.

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

If you already know everything, why are you on this list? If you don't know
everything, then please, stop acting like it.

Vitaliy

2008\07\07@180217 by Tomás Ó hÉilidhe

picon face

Vitaliy wrote:
>> Moot? Really? A class is the actual type. An object is an instance of
>> the class. I hope you don't intermix the terms.
>>    
>
> It's really neither (we're working in C, remember?).
>  

The concept of class and object transcend any one programming language.
The folks on comp.programming talk about these concepts all the time
without mentioning any particular language. I should get a handle on
these concepts instead of spending your time saving face with uniformed
responses such as "that's a moot point".

Now I hate to come across as condescending or derogatory, but if someone
says to me that they have a function such as:

   ObjectName_Function()

then it shows that they've a very fundamental misunderstanding of what
an object is and what a class is. Judging by your demeanour so far
you'll probably take that as an insult and come back with some sort of
quip about me being a troll, but maybe you'll take the time to learn the
distinction.

An object and a class are very different things. A class describes a
type, it lists the member functions that can be invoked upon an object
of the type, and it lists the data that's present in an object of the
type. A class can be thought of as a mould from which objects can be
created. A object is an actual instance of the class, it's a
*definition* of actual data that takes up memory at runtime. If you've
got three objects, you've got three chunks of memory for the member data.

Member functions work on objects. If you don't have an object, then you
can't call a member function PERIOD. Classes can have a special kind of
function called a "static member function", but these are no different
than normal functions and they don't constitute "object-orientated
programming".


> I prefer to call it an
> "object" because I'm not using it to instantiate anything, I can't derive
> anything from it -- but I am treating it as "something with
> responsibilities". Or, if you like, "a collection of related functions and
> data".
>  


Congratulations you've just describe OO programming. Unfortunately
though you don't fully understand the concepts of classes and objects,
and possibly namespaces too.

Even if you have a class that only contains *static* member functions
and *static* member data, it's still a class. I believe they call such a
thing a "singleton", which is still not an object.


> It is silly to argue that you know better than me what I meant. My question
> referred to the subject of the email, not the paragraph preceding it.
>  


Silly? Well considering I was right I don't find it too silly. You
talked about making code simpler by changing something like:

   PORTA = 0b1101;

into:

   TurnOffSensor();

This is what I replied to. Note that this "making simpler of things" is
orthogonal to OO programming.


> The books I've read ("Code Complete" comes to mind), and personal experience
> tell me it's better to "go over the code at the end". Optimizing parts that
> are a not the bottlenecks is a waste of time, and since usually there is a
> tradeoff (readability vs performance) it makes using and maintaining the
> code more difficult than necessary. In the particular case we're discussing
> (using macros or functions to encapsulate one-liners), this is largely
> irrelevant.
>  


For every one good programming book, there's 50 crap ones (if not a
hundred).

If a particular piece of code is called a lot in a program, it can make
a MASSIVE difference. It can mean your program won't fit on the chip, or
it could mean your display multiplexer flickers.


> When I read some of your comments, I find myself thinking that perhaps
> you're a troll sent by Olin to prove his point that newbies need to be
> publicly embarrassed to teach them a lesson. :)
>  


Then go ahead, feel free to embarrass me and bring me down to earth.

And as for taking heed in what Olin says... well.. sure he might know
about electronics... but his social skills register a negative on a
scale of 1 to 10.


> You're either a troll or a very thick-skinned newbie, so I will take the
> bait and say that I would at least do a bit of research, before proudly
> announcing my ignorance to the world.
>  


See this is where we differ. I proudly announce my ignorance to the
world everyday. I'm under no illusions that there's people out there who
are more intelligent than me and who are more knowledgeable than me, but
I also know that I can learn from these people and become more
proficient, perhaps even surpassing them one day. I'm 21 so it looks
like I've got half a century to get up to speed, if not more depending
on whether I keep taking cod liver oil everyday.

First I get a private e-mail from you calling me a "know it all" because
I was kind enough to share some knowledge, and now I'm a troll because I
won't back down in telling you you have a misunderstanding of objects
and classes.

Great character you have there.

Now as for labelling me a "newbie", well you'll have to be specific. I'm
new to the Piclist, that's true. I'm relatively new to electronics, I
only started three years ago. As for programming, well I've been at it
10 years now and I feel I've a very solid understanding of C and C++,
which is why I feel I'm "informed enough" to tell you that you're just
plain wrong in calling it ObjectName_Function.


> If you already know everything, why are you on this list? If you don't know
> everything, then please, stop acting like it.


..oh this is really laughable. How many questions do I ask a week on
this mailing list? Take a rough guess, a ballpark figure. You could fill
a warehouse with what I don't know about electronics, and I openly admit
this. Therefore, how am I a "know it all"?

When it comes to computer programming though, I have more answers than
questions, which is why I replied to your original post, and which is
why I (politely) pointed out your error that you said ObjectName instead
of ClassName. Note that my response was worded as "Do you mean
ClassName?" instead of coming out with a derogatory ridiculing response.
Unfortunately though you responded negatively to my kind manner, and
from what I can gather, you replied with "that's a moot point" for no
other reason than to save face. You then went on to take the time to
write me a private mail in which you called me a "know it all", which
further leads me to believe that you were embarrassed and felt the
compulsion to direct ridicule on me so as to alleviate it from yourself.
But alas I had no intent to ridicule you, I just wanted to point out
that you're wrong in saying ObjectName, and I hoped that you'd learn
from it. Unfortunately though I'm a troll for that.

If you'd like to present me with an alternative description of classes
and objects, or if you'd like to prove me wrong, then I'll gladly
entertain the discussion. Who knows you might even learn something from it.

2008\07\07@182313 by olin piclist

face picon face
Tomás Ó hÉilidhe wrote:
> The concept of class and object transcend any one programming
> language.

But they can also have different names.  In some languages it wouldn't be
wrong to say "type" instead of "class", for example.

> I should get a handle on
> these concepts instead of spending your time saving face with
> uniformed responses such as "that's a moot point".

That's really arrogant for someone that has asked a lot of stupid questions
here lately.  Vitali's first language isn't english, although he does quite
well with it.  A better response might have been "whatever", which basically
says, "Look, this is immaterial to the larger point at hand.  You may be
right, but it really doesn't matter.  It would be nice if you stopped
wasting time and derailing the thread with nitpicks so we can discuss the
main point.".

Once you've earned some respect and trust here and have added useful
content, you get to occasionally nitpick about something, but you're
currently negative in that category.

Let it be already.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\07@193530 by Tomás Ó hÉilidhe

picon face
Olin Lathrop wrote:
> Tomás Ó hÉilidhe wrote:
>  
>> The concept of class and object transcend any one programming
>> language.
>>    
>
> But they can also have different names.  In some languages it wouldn't be
> wrong to say "type" instead of "class", for example.
>  


A class is a kind of type. Here are other kinds of types:

   struct
   enum
   union
   intrinsic


> Vitali's first language isn't english, although he does quite
> well with it.


You're tryna pull *that* one?! You don't need to be able to fluent in a
language to know the difference between two words, especially when
they're "academic" words.

My first language isn't Umakar, and I'm not nearly fluent in it, but I
know the following about it: "object" translates as "iman", and "class"
translates as "err".


>   A better response might have been "whatever", which basically
> says, "Look, this is immaterial to the larger point at hand.  You may be
> right, but it really doesn't matter.  It would be nice if you stopped
> wasting time and derailing the thread with nitpicks so we can discuss the
> main point.".
>  


Looks like you too, Olin, don't understand objects and classes. If you
did, you'd know that it's not an immaterial point at all. Nor is it a
nitpick.

Calling an object a class is a BIG no-no -- a gargantuan no-no even. It
is one of the most fundamental no-no's of OO programming. To compare it
to something you might understand, here's what happened one day when I
was doing electronics in college:

   * We had pretty good power supplies that could go as high as 30 V
and also had a current limiter which you could set anywhere from 1 mA to
2 A.
   * One day, one of the less proficient students made up a circuit.
   * He set the power supply to 5 volts.
   * He applied power to his circuit.
   * A resistor started smoking.

Next he exclaimed "aw shit I set the current too high". Now this student
obviously had a very fundamental misunderstanding of electricity. He
didn't understand that the current flow was dependant upon the voltage
applied, and that the current limiter was only there as a failsafe. He
had some strange idea that the power supply's current limiter was
actually a facility he could use to set how much current flows through
his circuit. This fundamental misunderstanding electricity is on par
with calling a class an object.

I would hazard a guess that if you witnessed this person exclaiming "I
set the current too high", that you wouldn't let it go.

If Vitality doesn't want to learn the truth then fair enough, but I'll
combat every effort he makes to perpetuate and propagate the mistake.


> Once you've earned some respect and trust here and have added useful
> content, you get to occasionally nitpick about something, but you're
> currently negative in that category.
>
> Let it be already.


I find it magnificent that you think I'd pay a blind bit of notice to
what *you* deem as "someone having earned respect". I've already made
very clear my opinion of you.

I have been contacted by two moderators so far. One of them said that
"personality clashes occur". Personality clashes don't just "occur". I
know plenty of people who have a personality different to mine, but I
get on fine with them. A friend of mine is a born-again Christian while
I'm a passive Atheist, but we get on fine. A friend of mine drinks daily
while I don't drink at all. We get on fine. A "personality clash"
between two people doesn't just occur -- it results from at least one of
the people being unfriendly and nasty.

2008\07\08@013634 by Vitaliy

flavicon
face
Tomás Ó hÉilidhe wrote:
[snip]
> Member functions work on objects. If you don't have an object, then you
> can't call a member function PERIOD. Classes can have a special kind of
> function called a "static member function", but these are no different
> than normal functions and they don't constitute "object-orientated
> programming".

Well that's exactly my point. I am calling "member functions" that operate
on data, without instantiating anything. The entity that I created is
neither a class nor an object, hence "it's a moot point".

{Quote hidden}

You incorrectly interpreted the scope of the comment. I meant it to apply to
the subject of the post, you thought it applied to the paragraph immediately
preceding it. It's OK to incorrectly interpret the meaning, but it is silly
to insist that you can read my mind.

{Quote hidden}

"Code Complete" is crap?

>> When I read some of your comments, I find myself thinking that perhaps
>> you're a troll sent by Olin to prove his point that newbies need to be
>> publicly embarrassed to teach them a lesson. :)
>
> Then go ahead, feel free to embarrass me and bring me down to earth.

I don't believe Olin's method actually works. The only thing it does, is
make me feel a little better (but it's an evil sort of better, since it's
done at your expense).

> And as for taking heed in what Olin says... well.. sure he might know
> about electronics... but his social skills register a negative on a
> scale of 1 to 10.

I'm afraid your social skills aren't a 10, either. :)

> See this is where we differ. I proudly announce my ignorance to the
> world everyday. I'm under no illusions that there's people out there who
> are more intelligent than me and who are more knowledgeable than me, but
> I also know that I can learn from these people and become more
> proficient, perhaps even surpassing them one day.

I routinely admit my own ignorance, but I am not proud of it. Embarrassment
of my ignorance is one of the incentives I have to increase my knowledge.

> First I get a private e-mail from you calling me a "know it all" because
> I was kind enough to share some knowledge, and now I'm a troll because I
> won't back down in telling you you have a misunderstanding of objects
> and classes.

No, you're a troll because you are posting messages which are obviously
provocative.

> Now as for labelling me a "newbie", well you'll have to be specific. I'm
> new to the Piclist, that's true.

That's exactly how I meant it.

>> If you already know everything, why are you on this list? If you don't
>> know
>> everything, then please, stop acting like it.
>
> ..oh this is really laughable. How many questions do I ask a week on
> this mailing list? Take a rough guess, a ballpark figure. You could fill
> a warehouse with what I don't know about electronics, and I openly admit
> this. Therefore, how am I a "know it all"?

It's your attitude. A "know-it-all" is not one that doesn't ask any
questions. It's one who thinks he always knows best what the right answer
is.

> Unfortunately though you responded negatively to my kind manner, and
> from what I can gather, you replied with "that's a moot point" for no
> other reason than to save face.

No, I said what I said because I meant it. "If you were right, I would agree
with you". :)

> You then went on to take the time to
> write me a private mail in which you called me a "know it all", which
> further leads me to believe that you were embarrassed and felt the
> compulsion to direct ridicule on me so as to alleviate it from yourself.

I sent you a private message because I did not want to call you a
"know-it-all" on-list. Publicly embarrassing newbies to teach them a lesson
is Olin's job. :)

> If you'd like to present me with an alternative description of classes
> and objects, or if you'd like to prove me wrong, then I'll gladly
> entertain the discussion. Who knows you might even learn something from
> it.

The discussion would not be productive. I feel that my arguments fall on
deaf ears (you've already made up your mind), and you probably feel the same
way.

The best thing to do in this situation, is for you to take a break from the
PICList. A quick search reveals you've been posting every day, without
interruption, since you made that first post on June 13th. 150+ posts in 25
days causes increased levels of irritability and poor judgement. I'm
speaking from experience.

Best regards,

Vitaliy

2008\07\08@034614 by Tamas Rudnai

face picon face
Tomas,

I am really tired reading of your posts. Being 21 you have a big face and an
even bigger ego. How the hell you think that it is only you who started
programming or doing electronics at the age of teen? How the hell you think
that you have better experience than thos that are at least twice as old as
you are? And who are you to insulting people continuously, huh? Maybe you
are one of those kids from Corduff or Ballymun. Anyway, don't worry about
electronics, 7 more years and you will have more answers than questions...
<grin> Hope you are not the representations of the younger generation.

That's all I wanted to say, thank you.
Tamas




On Tue, Jul 8, 2008 at 12:34 AM, Tomás Ó hÉilidhe <toespamspam_OUTlavabit.com> wrote:

{Quote hidden}

>

2008\07\08@080906 by Tomás Ó hÉilidhe

picon face

Tamas Rudnai wrote:
> Tomas,
>
> I am really tired reading of your posts. Being 21 you have a big face and an
> even bigger ego. How the hell you think that it is only you who started
> programming or doing electronics at the age of teen? How the hell you think
> that you have better experience than thos that are at least twice as old as
> you are? And who are you to insulting people continuously, huh? Maybe you
> are one of those kids from Corduff or Ballymun. Anyway, don't worry about
> electronics, 7 more years and you will have more answers than questions...
> <grin> Hope you are not the representations of the younger generation.
>
> That's all I wanted to say, thank you.


You're welcome, thanks for sharing, glad to see you got that mental
masturbation out of the way, maybe now you can contribute productively.


2008\07\08@083319 by olin piclist

face picon face
Tomás Ó hÉilidhe wrote:
> You're welcome, thanks for sharing, glad to see you got that mental
> masturbation out of the way, maybe now you can contribute
> productively.

You're lucky I'm not a PICList admin, because I would now suspend you for a
week.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\08@084347 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: @spam@piclist-bouncesKILLspamspammit.edu [KILLspampiclist-bouncesKILLspamspammit.edu] On Behalf
> Of Tomás Ó hÉilidhe
> Sent: 08 July 2008 00:35
> To: Microcontroller discussion list - Public.
> Subject: Re: [EE] Implementing OOP features in C
>
>
> He
> had some strange idea that the power supply's current limiter was
> actually a facility he could use to set how much current flows through
> his circuit.

Providing the current limiter is within it's compliance range that is exactly what you can use it for.  Obviously the current is regulated by changing the output voltage, but in terms of an adjustable current source that is a given.

I can tell from your agonizing pedantry that you have spent far too much time on the usenet programming groups.  Whilst starting as many threads as possible on similar subjects and arguing at length over petty terminology issues might impress the social lepers on comp.lang.*, it won't win you any friends on here.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\07\08@104407 by Herbert Graf

flavicon
face

On Tue, 2008-07-08 at 13:08 +0100, Tomás Ó hÉilidhe wrote:
> You're welcome, thanks for sharing, glad to see you got that mental

Tomas has been placed on moderation.

Please end any sort of flaming in this thread. I've nothing wrong with
the thread itself (admittedly it's over my head), but no more personal
insults please.

Thanks, TTYL

2008\07\08@164344 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> I should get a handle on
>> these concepts instead of spending your time saving face with
>> uniformed responses such as "that's a moot point".

>That's really arrogant for someone that has asked a lot of stupid questions
here lately.  Vitali's first language isn't english, although he does quite
well with it. <

Sadly, at this point I am more fluent in English than in any other language.
"Use it, or lose it." :-(

> A better response might have been "whatever", which basically
says, "Look, this is immaterial to the larger point at hand.  You may be
right, but it really doesn't matter.  It would be nice if you stopped
wasting time and derailing the thread with nitpicks so we can discuss the
main point.". <

You could interpret it that way, but I really consider it to be a moot
point. You can't really "use" a class, except to instantiate an object. On
the other hand, by definition you cannot have an object without
instantiating it from a class. Classes in the true OOP sense also have
certain attributes, for example it is assumed that you should be able to
derive new classes that inherit the behavior of their parent classes.

What I have (for the sake of this example), is a class called uart.c, with a
corresponding uart.h file. Uart.c has some private functions and data, and
public "methods" exposed via the uart.h file. I can do things like:

Uart_SendMessage("Hello World");
Uart_SetBaudRate(115200);

..without instantiating the Uart object. And in the current implementation,
there are no provisions for inheritance, or deriving multiple instances of
Uart.

I prefer to think of these chunks of related code and data as "objects", but
I'm fine with someone else referring to them as "classes". Arguing in favor
of one over the other is like arguing whether the armadillo is a porcupine
or a turtle.

Vitaliy

2008\07\09@014109 by Luis.Moreira

picon face
Hi Vitality,
Now you really started things... it is obviously a turtle:)

               Luis



-----Original Message-----
From: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [spamBeGonepiclist-bouncesspamBeGonespammit.edu] On Behalf
Of Vitaliy
Sent: 08 July 2008 07:10
To: Microcontroller discussion list - Public.
Subject: Re: [EE] Implementing OOP features in C

Olin Lathrop wrote:
>> I should get a handle on
>> these concepts instead of spending your time saving face with
>> uniformed responses such as "that's a moot point".

>That's really arrogant for someone that has asked a lot of stupid
questions
here lately.  Vitali's first language isn't english, although he does
quite
well with it. <

Sadly, at this point I am more fluent in English than in any other
language.
"Use it, or lose it." :-(

> A better response might have been "whatever", which basically
says, "Look, this is immaterial to the larger point at hand.  You may be
right, but it really doesn't matter.  It would be nice if you stopped
wasting time and derailing the thread with nitpicks so we can discuss
the
main point.". <

You could interpret it that way, but I really consider it to be a moot
point. You can't really "use" a class, except to instantiate an object.
On
the other hand, by definition you cannot have an object without
instantiating it from a class. Classes in the true OOP sense also have
certain attributes, for example it is assumed that you should be able to

derive new classes that inherit the behavior of their parent classes.

What I have (for the sake of this example), is a class called uart.c,
with a
corresponding uart.h file. Uart.c has some private functions and data,
and
public "methods" exposed via the uart.h file. I can do things like:

Uart_SendMessage("Hello World");
Uart_SetBaudRate(115200);

..without instantiating the Uart object. And in the current
implementation,
there are no provisions for inheritance, or deriving multiple instances
of
Uart.

I prefer to think of these chunks of related code and data as "objects",
but
I'm fine with someone else referring to them as "classes". Arguing in
favor
of one over the other is like arguing whether the armadillo is a
porcupine
or a turtle.

Vitaliy

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...