This whole thread just proves/reminds that in reality three things are needed:

1) brains;
2) good scoping rules (e.g. "C", Perl, Pascal have them);
3) good preprocessor.

C++ originally was just a preprocessor.

My point is that OO featurer - if/when desired - should be implemented at source level.

Inheritance is not a value by itself - it's a means to achieve code extensibility, but just a means.

So in Java if I don't say super() and the subclass has no parameter-less constructors, it calls a blank one?

That part of the language specification I linked tells you that if you don't start with a constructor call, the compiler will insert a call to a parameter-less constructor.

What happens if you call a parameter-less constructor that doesn't exist must be discussed elsewhere in the specification. But whatever that is, it happens the same regardless of whether you coded the call to the parameter-less constructor yourself or whether the compiler added it for you as described in 8.8.7

In C++ there are rules for whether a call to a parameter-less constructor that you haven't defined causes the compiler to generate an error message or whether it causes the compiler to invent a parameter-less constructor for you. As far as I recall, those rules are similar in Java.

I got this error compiling my C++ program. I don't understand why it says that I cannot call a base class's method.

When you switch the second and third parameters, it tends not to be able to find the function.

The Makefile is much more complex than it needs to be - use make's implicit rules and GCC's dependency checking:

OO is entirely possible with C, BTW.
For example:
http://www.eventhelix.com/RealtimeMa...0Source%20Code
http://www.bolthole.com/OO-C-programming.html
http://bytes.com/topic/c/answers/530...lementing-oo-c

I often use C to do OO code.

If you're looking for a language that strongly encourages OO, maybe Ruby or Obj-C (as was suggested earlier). I wouldn't recommend Java, just because years of use have taught me that there is almost always a better way :D

It is pretty hard to tell you the error in your code when you didn't show us the code.

Despite that, tuxdev managed to tell you the cause of the error that is reported as line 7 of main.cpp

Looking at the messages, I can't be sure the error reported as line 8 is an unrelated error (as it appears) or a consequence of the line 7 error. Often it is best to fix errors as you understand them and then see if later errors go away or change.

If the second error remains, post the related code.

What does that mean?

So as I understand pkg-config sets the right flags for the library and -Werror makes the compiler treat warnings as errors.

I still don't know what -Wall, -Wextra, Weffc++, and -MD mean.

I don't get this either. What are .d files, too?

I knew about using structs instead of instance variables and functions that take the struct as a parameter instead of methods, and I like this technique, but I really need inheritance and polymorphism, too, and it is not obvious to me how you would do this as an extension of this technique.

But I wonder how i.e. GTK+ does it? it is written in pure C but still has some kind of object hierarchy.

-Wall and -Wextra makes gcc complain more about stuff you might be doing wrong. It has saved me from myself on many, many occasions.

-Weffc++ produces warnings based on some of what Scott Meyer wrote about in his "Effective C++" book series. Get a copy if you don't already have one and read through it.

I actually also use -ansi -pedantic so my C++ is as standard as possible, but that's not acceptable for some stuff.

-MD makes it produce .d dependency files which are then included into the Makefile for later builds. If you don't do some kind of automated dependency tree generation, it will bite you eventually.

"LINK.o = $(LINK.cpp)" tells make to link .o files together with the C++ linker (g++) rather than the default C linker (gcc).

".PHONY = all clean" tells make that the "all" and "clean" targets don't actually refer to files and should always be considered out-of-date.

"$(wildcard src/*.cpp)" returns a list of files that match the glob src/*.cpp

"main: $(SRCS:%.cpp=%.o)" tells make that the "main" file can be built from files in the SRCS variable with their extensions changed from .cpp to .o. make already knows how to make .o files from .cpp files.

There's really no point in debating it, but it is certainly possible, as demonstrated in this nice article. He comments that C is a non-OO language, but I think what he really means is that C doesn't force OO like some languages do.
http://www.embedded.com/97/fe29712.htm

In all fairness, OO is not a one size fits all approach to coding. There are, as always, many approaches to any problem. I usually consider that it comes down to either dev time or execution time (memory, etc). The determination is usually made by the company responsible - with F/OSS projects, it often tends to be determined by the project lead.

An amusing rant against C++: C++ Frequently Questioned Answers.

I still see flaws with the pointer-to-superclass approach - What if you don't know the exact level of hierarchy a variable was created?

You're fundamentally assumed to know this. If you can't or don't want to keep track of it, of course the computer can help.. Hey, that's already been done and it's called "C++"!

The one thing about C++ using the same linker as C is that you *know* every feature in C++ can somehow be done in C, with various levels of pain.

http://yosefk.com/c++fqa/defective.html

What's better about C:

See "Duplicate Facilities"

What's better about Java:

See "No high-level built-in types"
See "Manual memory management"