Maximum PC

As the topic, I have quite experience about C programming, like kernel, driver and application on Linux.
It's really difficult to change the way of thinking into orient objective.
Can someone give some help ?
Thank you

While there are some major differences, organization wise, if you have good habits with C, then they carry over to C++.

For example, say you have in C source files foo.c and foo.h. Everything you declare in foo.h and include in other files is considered public. The rest of the functions and variables in foo.c declared static are considered private. Now I haven't dived much into C++, but I'm going on a whim and say that when you make an object in C++, you're declaring up front in the header what's public and what's private, so you don't have to use that static keyword all the time. The catch is, if you declared a function in the header, you better define it somewhere in a .cpp file.

It's a different way of doing things, but otherwise, like I said, if you have good organization habits, then the transition isn't bad.

I found over the course of my software engineering career that you can have C++ like functionality in C within limits. It's just hard to do.

Thank you for your words.
It might be a long time to get used to it.
There are lots differences between them like objective thinking. Practice is the top notch way I guess.

Nice LatiosXT -- I didn't think too many people knew that one.


I believe the static keyword operates the same in C++. Thinking outloud... how else could C++ be a super-set of C? I might look that up later; It's been a while for me too. In the context of OOP, which isn't part of standard ANSI-C, the class, methods and members are designated as public, private or "friends" (pita C++) in the header file.


Outside of OOP?

Not sure what you mean by "outside of OOP?"...

And yes, I'd believe C++ uses the "static" keyword in the same manner as C. But point being, "private" supersedes it. It's also kind of unintuitive that 'static" means "private". But you know, C is weird in it's own ways.

On a side note, C# also uses "static" on objects. In which case, it's always instantiated, persistent, and basically anyone can access it. A global object, if you will. Not sure if C++ does this too.

We should have DJSpin check this, but I don't believe this is correct for C#. I'm certain that it is incorrect for Java.

In modern OOP languages (at least all of the ones that I'm familiar with), static has no implications with regard to access. The static keyword is used to create fields and methods that belong to the class, rather than to an instance of the class. You set the access to static fields and methods the same way as instance fields and methods (eg public static int foo = 0;). The code below is a simple example of how static fields and members can be used in Java.


I think that a lot of people probably believe that the notion of static fields and members is derived primarily from the static keyword in C; However, based on the history of the people involved in the creation of OOP, Java and related technologies, I think that the concept of a closure, which were used in Scheme, Lisp, ML, Smalltalk and a few other languages prior to the creation of OOP, had at least as much influence, if not more, on the use of static in modern OOP languages [Alan Kay invented OOP; James Gosling wrote the first version of Emacs for Unix; Guy Steele was involved with the creation/standardization of both CL and Java languages (and others)]. Granted, closures can be used in a variety of ways that are very different than static methods/fields, but they're often used in a similar manner. If you don't believe that closures were an influence, try writing the equivalent code in C or C++ (w/o using OOP). The CL code below mimics the functionality of the Java code using closures.


Of course, the Java code is far longer than the CL code. Sometimes I wonder how much of my life has been wasted paging up and down because "good" imperative language coding practices spreads even relatively simple code across several screens. This probably explains why nobody in the "old days" ever thought to create a monitor that could be rotated vertically.

Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.
Alan Kay -- The Computer Revolution hasn't happend yet -- Keynote, OOPSLA 1997

You had mentioned that you can have C++ like functionality in C within limits (if you work harder). I couldn't think of many features of C++ that C doesn't support aside from OOP. Granted, the STL has some data structures that C doesn't include, which are nice, but I think most C programmers can find equivalent items relatively easily. I was mostly wondering if there is anything in the embedded space that C++ seems to make easier than C.


Sure is... there is no rule that everything has to make sense, right? =)


How do we convince people that in programming simplicity and clarity —in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure?
--Edsger W. Dijkstra

Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.
ACM Queue A Conversation with Alan Kay Vol. 2, No. 9 - Dec/Jan 2004-2005

If the pros at Sun had had a chance to fix Java, the world would be a much more pleasant place. This is not secret knowledge. It’s just secret to this pop culture.
ACM Queue A Conversation with Alan Kay Vol. 2, No. 9 - Dec/Jan 2004-2005

A doctorate programmer named Miro Samek (whom I had the pleasure of meeting, since he came over to teach a course where I work), used a few things you can do in C that are kind of like how objects are in C++ with a framework he developed (called QP). I don't know the details too well, but it was described in one of his books and from what I recall, you work with structs in such a way that they are the classes, and you can essentially have inheritance (only one level) and public/private/protected members. Anyway, he dubbed this C+, since some of OOP was there, but not quite the whole shebang from C++.

Also I've found no real reason to use C++ in an embedded environment. I don't feel there's much advantage to OOP in a primitive system. And you could pretty much imitate it anyway through clever use of your source and header files.

From what I gather having worked with quite a few older programmers in aerospace is that there were a lot of people trying to shoehorn OOP into C during the mid-80's and early 90's. It reminds me of Greenspun's Tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.


Yeah, I couldn't think of any reason for using OOP in an typical embedded environment either, but I haven't done much more than initializing hardware and placing/retrieving sensor data from a buffer either. OOP might make some data structures a bit safer / easier to use assuming you needed a circular linked list, hash table or something more complex than an array, but I don't think it would improve things significantly beyond standard C.

QP was developed for embedded systems in mind, so the thing is damn fast.

I also work mostly on event driven systems where they just need to react to something. The application code there isn't very complex (or rather, it shouldn't be). So even there, I haven't found use for anything more complex than a simple struct. Heck I think the most complicated thing I've done, data structures wise, is a pimpl list.

You got me with that one. What the heck is a pimpl list?

A pimpl list is short for pointer implementation list. Effectively it's what you call an interface in OOP land. But not quite.

First you declare some functions (what your application will be calling) and a struct of function pointers. As an example, let's say we're doing animals. We have an "animal.h" that has this definition.


Then in our "animal.c"

move_animal and sound_animal are what get called in the application. When you call them, they call another function in the struct defined earlier. The catch is that these functions must be defined somewhere else and properly pointed to, otherwise you'll be following a null pointer. More on how to properly set this up later...

Then we have a "dog.c"

In the bottom, you're mapping out which function in "dog.c" goes to the animal_impl struct. So let's say we also have a "dolphin.c"

However, both "dog_impl" and "dolphin_impl" need to be global. This changes "animal.h" to...

And you need to add another function in "animal.c" to set up which function ultimately gets called, hence the "set_pimpl" function... So we have:

So if you called move_animal when pimpl = dog_impl, you would call walk() in dog.c.

It's a pain in the ass to debug when you aren't aware of pimpl lists, because it's not intuitive where any of this goes. But it's a handy tool. In this case, the mainline application code doesn't need to know if it's a dog or a dolphin. It just calls generic functions that mean move the animal or have the animal make a sound.

And heck, you probably don't need a set_pimpl function. You could have as many animal_impl variables as needed.

In some respects, it goes beyond an interface. The hiding of the underlying function names [eg bark() w/ make_sound()] fulfills the role of the adapter design pattern (pretty closely); However, the ability to define an animal parameter then pass an "instance" of animal to the function is essentially an ad hoc version of polymorphism.

When I read pointer implementation list, I thought duh... It's just a pointer implementation for a list (ie the ADT List). It's obviously not -- talk about being badly name! It's a fairly interesting programming technique. When did you first hear about or use it? I didn't find any references to a pimpl list in either of my C programming books or in The Art of Programming. Also, a Google search of "pimpl list" doesn't return much of anything either.

Yeah, I bet. I was trying to think of a method for making the implementation a bit easier. Unfortunately, my C programming is pretty rusty as I don't have a C compiler on my laptop, but I take it that typedefs couldn't be used to achieve the same sort of functionality?

Common Lisp went through a period prior to CLOS (the Common Lisp Object System -- an extremely rich OOP implementation) where people used the defstruct macro to implement quite a bit of standard features of OOP. Of course, it wasn't nearly THAT painful. =)

The generic term for pointer implementation is opaque pointers. I found this out (among other neat things) at work, where ironically, the software where all of this was contained is hailed by those who touch it to be an exercise in how not to code something. Well at least the parts that my supervisor and his team didn't improve.


I'm not sure what you mean by this, but I believe you typedef a struct in order for the compiler to treat it as any other data type. Otherwise you have to do something like "struct animal_impl foo" or "struct animal_impl bar".

I should probably mess around some more, since I always typedef my structs.

Yeah you can mark a class as static. Static classes are available on every project, so in a sense it functions like a global object. Static classes are, for the most part, the basis of extension methods in C#. It's actually not good to use static classes, only because as functionality changes, you can't subclass it. Also, if you mark a class static it cannot be mocked/faked for unit testing.

http://stackoverflow.com/questions/2413 ... in-c-sharp

http://stackoverflow.com/questions/2056 ... ach#206481

I need to issue a correction to something that I previously stated: You can declare an inner class as static in Java.


Interesting, I'll need to allow this concept some time to distill. My first inclination is to file this as another example of OOP being overdone / overused. The only real benefit appears to be that the compiler will ensure that a public constructor is not unintentionally added to a class which seems rather unnecessary. Simply create a private constructor and declare the class final (which reduces unnecessary syntax). Also, the only reason I've seen developers create a class filled entirely with static members and methods is because some OOP languages are forcing developers to use OOP machinery under circumstances when the use of constant variables and functions inside of a namespace or package is a more natural alternative.

Further complicating the issue are static constructors, which can be used to perform one time initialization of fields, in a class that is declared static. One of the reasons the reasons that constructors were adopted in OOP languages is that linking initialization with object instantiation is MUCH safer than separate initialization and instance routines. Unfortunately, the combination of a static class and constructor allows precisely this sort of dangerous behavior to occur (because the class methods are static, you can call them with Class.Method() not Obj.Method() w/o having called the constructor). I don't believe this error can be caught at compile time, but I'd need to do some testing to be sure if this is the case. In this case, a Singleton is probably the preferred solution.

Anyways, these are just some initial thoughts: unnecessary syntax, unnecessary OOP, possible unsafe usage. I'd be interested in hearing from anyone that has used, especially beneficially, static classes or constructors.

I've used static classes in C# for my GUI based debug programs that use serial ports. I was probably re-inventing the wheel for some of the functionalities, but basically it was the serial port controller (instead of a GUI form handling it), and anyone who needed data would subscribe to it.

I've been trying to do my C# GUI programs more organized. i.e., the Windows Forms objects should only contain GUI thread code and helper functions. If I have something like an I/O handler, it should be handled separately (and in fact, the .NET Framework gets pissy if you try to modify a GUI element from say a Serial Port handler).

I was reviewing Peter Norvig's article on Design Patterns in Dynamic Languages (which is an excellent article that I would suggest everyone read). Under the section on "Level of Implementation of a Pattern" he mentions that the addition of classes to C++ made the Encapsulated Class design pattern invisible in C++ which reminded me of your comment above.

I think that it would be pretty useful if someone took the time to create a matrix of design patterns (rows) and programming languages (cols) and filled each cell with the level of implementation and other relevant notes for each language. I should check to see if the Oregon DP archive includes something like this already though.