C++ programming style

Question

I\'m an old (but not too old) Java programmer, that decided to learn C++. But I have seen that much of C++ programming style, is... well, just damn ugly!

All that stuff

Answer 1

Like a stereotypical programmer who programs in one specific paradigm, you decided that certain things that aren't familiar with you is just ugly.

C++ is a different language, it's multiparadigm, and it has lots of carry-overs from C. As other have stated, that's just the way it is.

Header files are there for the compiler to check basic syntax without knowing the implementation. If you're a heavy Java programmer, you should be fairly familiar with the whole program to an interface concept. Think of the header file is where the interface is.

If you don't believe me, go look at some Mods out there for games. It's entirely possible to find the CryEngine2's header file somewhere because Crysis mods would need to talk to it, but it doesn't need to understand how it works. The header files will define how ultimately a calling function should setup the stack to call another function.

Not to be condensending, but I think what you really need is to program in something completely different. Research other paradigms, and find some languages, and start writing some toy applications. At first, things would look ugly, but you'll eventually see the advantages.

I said the same thing about functional programming too. Now I complain about how PHP butchered functional programming with arrays.

Answer 2

In addition to what others have said here, there are even more important problems:

1) Large translation units lead to longer compile times and larger object file sizes.

2) Circular dependencies! And this is the big one. And it can almost always be fixed by splitting up headers and source:

// Vehicle.h
class Wheel {
    private:
        Car& m_parent;
    public:
        Wheel( Car& p ) : m_parent( p ) {
            std::cout << "Car has " << m_parent.numWheels() << " wheels." << std::endl;
        }
};

class Car {
    private:
        std::vector< Wheel > m_wheels;
    public:
        Car() {
            for( int i=0; i<4; ++i )
                m_wheels.push_back( Wheel( *this ) );
        }

        int numWheels() {
            return m_wheels.size();
        }
}

No matter what order you put these in, one will always be lacking the definition of the other, even using forward declarations it won't work, since in the function bodies are using specifics about each class's symbol.

But if you split them up into proper .h and .cpp files and use forward declarations it will satisfy the compiler:

//Wheel.h
//-------
class Car;

class Wheel {
private:
    Car& m_parent;
public:
    Wheel( Car& p );
};

//Wheel.cpp
//---------
#include "Wheel.h"
#include "Car.h"

Wheel::Wheel( Car& p ) : m_parent( p ) {
        std::cout << "Car has " << m_parent.numWheels() << " wheels." << std::endl;
}

//Car.h
//-----
class Wheel;

class Car {
private:
    std::vector< Wheel > m_wheels;
public:
    Car();
    int numWheels();
}

//Car.cpp
//-------
#include "Car.h"
#include "Wheel.h"

Car::Car() {
        for( int i=0; i<4; ++i )
            m_wheels.push_back( Wheel( *this ) );
}

int Car::numWheels() {
        return m_wheels.size();
}

Now the code that actually has to know specifics about the second class can just include the header file which doesn't need to know specifics about the first class.

Headers just provide the declarations while source files provide the definitions. Or another way to say it: Headers tell you what is there (what symbols are valid to use) and source tells the compiler what the symbols actually do. In C++ you don't need anything more than a valid symbol to begin using whatever it is.

Trust that C++ has a reason for this idiom, because if you don't you will make a lot of headaches for yourself down the line. I know :/

Answer 3

Calling functions out of nowhere, instead of using methods inside classes; All that just seems... wrong!

So finally, is there any reason for me to continue with this massacre to the OOP

Well, calling functions that don't belong to classes isn't OOP -- it's procedural programming. Thus, I believe you're really having a difficult time breaking out of the OOP mindset. (Certainly C++ has many ills, but procedural programming isn't one of them.)

C++ is a multi-paradigm language, not just an OO langage. Templates are a form of generic programming which can be applied to procedural, OOP, and meta-programming paradigms of C++. With the next C++ standard, you'll see some functional paradigms added as well.

All that stuff of putting the class definition in a header file, and the methods in a different source file;

This has its origins from the C programming language, back in the 70's. C++ was designed to be backwards compatible with C.

The D programming language is an attempt to fix many of the ills of C++ (and as I said earlier there are many), but maintain the good features of C++ -- including all the various paradigms C++ supports: procedural, OOP, metaprogramming, and functional.

If you want to break out of the OOP mindset, try D! Then, when you get a feeling for how to mix and match the different paradigms, you can (if you so desire) come back to C++ and learn to deal with its syntax and other ills.

P.S. I use C++ daily and I am a fan of it -- it is my favorite programming language. But as any experienced C++ programmer knows, C++ does have its ills. But once you master the different paradigms and know how to work around C++'s ills, you'll have an incredibly powerful tool (for that is all a language is) at your disposal.

Good luck in your adventures!

Answer 4

The style you program in is up to you. Just make sure you understand that "ugly" style others use.