Have you guys got a problem with the way I do things?

[K.I.L.E.R]

Tell me if anyone believes this is a problem and why.

I've been doing this last year on my assignments when I was required to use C++.
I place my classes within headers files(duh!) however the definition didn't always go into a CPP file.

My reason was simple, if a class was small, long lived(else it would be a struct) and wasn't complicated in any way I'd place the definition and declaration within the header file.

I haven't thought about this until know because I'm starting to do some serious work in C++ due to the fact I spent far too much time working with Java and not enough time in C++ since 2004.

Anyway is this a good practice?
The reason I do it is to save room.
I wish editors would integrate headers files and source files a lot better.

 

[_xxx_]

Every programmer will tell you something different and have different practices. To each his own, I'd say.

I'm the kind of "comment every shite double"-sicko, since when I look at some years old stuff I have to change for whatever reason it made me bleed quite a few times until I realized what I actually did in the code. So comments, comments,...blah.

 

[ERP]

Tell me if anyone believes this is a problem and why.

I've been doing this last year on my assignments when I was required to use C++.
I place my classes within headers files(duh!) however the definition didn't always go into a CPP file.

My reason was simple, if a class was small, long lived(else it would be a struct) and wasn't complicated in any way I'd place the definition and declaration within the header file.

I haven't thought about this until know because I'm starting to do some serious work in C++ due to the fact I spent far too much time working with Java and not enough time in C++ since 2004.

Anyway is this a good practice?
The reason I do it is to save room.
I wish editors would integrate headers files and source files a lot better.

The side effect to declaring inside the class definition is that the code will likely be inlined and at a minimum you'll get one copy of the code per module that includes the header and uses the class.

I happen to like declaring inline functions in the header, BUT..... if you have a large codebase any header change can mean an extremly painful recompile.

 

[K.I.L.E.R]

Thanks guys, also another thing.

Virtual inheritence can be used to achieve the same effects of Java interfaces.
True or false?
This is the way I've been using them, so if someone over here thinks otherwise then please tell me.

Oh and please don't tell me that Valve have abused virtual functions in HL2.

 

[Frank]

No. I mean, not in the sense as of why interfaces exist. In short, interfaces describe protocols.

Consider this: there is a reason why only C++ allows you to new objects based on more than one other object, while just about anything allows you to use as much interfaces as you want. The interface is only a framework that describes how you can use other, independent objects or streams.

In short: to specify an optional method, you make it virtual up front (not afterwards!). And for describing protocols, streams and other abstract things, you use interfaces.

And that's really how you should use them. Because, when you work on some program with a team, or use libraries from other people, you want a very strict description of how you should handle it. And not add your stuff on top by making one of the existing methods virtual, breaking lots of stuff and creating very nasty bugs and angry people. Which is exactly why interfaces exist.

 

[K.I.L.E.R]

Is the interface keyword in C++ only working on Microsoft compilers?

 

[ERP]

Virtual inheritence can be used to achieve the same effects of Java interfaces.
True or false?

A Java interface has specific semantic meaning. You can declare interfaces in C++ as pure virtual classes but you cannot guarantee that semantic meaning. i.e. Someone can later add a concrete member, or a default implementation.

Multiple public inheritence is generally considered bad practice except when your inheriting from interfaces, or using what are often termed "mixins", and I think the mixin argument is a bit dubious.

If you are concerned about performance, IMO you should only declare interface classes IF you have more than one implementation live in the codebase. In most cases it is completely pointless having an IRender interface since you are likely only ever going to instantiate one at a time.

Not having an abstract interface class doesn't mean you can't have a well defined interface, header files are as much an interface definition as interface class declarations. Some libraries ship with two different header sets, one for library development and one that hides implementation details and is avialable for client code.

 

[Frank]

Not having an abstract interface class doesn't mean you can't have a well defined interface, header files are as much an interface definition as interface class declarations. Some libraries ship with two different header sets, one for library development and one that hides implementation details and is avialable for client code.

Agreed. But it's about the direction you're looking at it, and if you do it up front or afterwards.

By creating an interface, you're saying: "this is how I want to interface with other stuff", or "this is how you should do it, to stay in line with everything else". While with a header file, you're saying: "this is how you can use my stuff".

Ok, it isn't as straightforward as that, but you know what I mean. And I agree, that random inheritance is very bad practice.

So, while you might only have a single instance of some class at a single time, it's still a very good rule of thumb to create (all) your interface(s) up front. And while that can be in another form than declarations of interface classes, it is almost certainly more productive for large projects to do that for everything, than keeping lists of things that work different, even if it might improve the performance a bit. Or having to figure out how each individual interface (the protocol/header file) is supposed to operate.

 

[ERP]

I'd actually argue that you should never speculatively inherit.
Inheritence is often better done during refactoring when what is shared and what is not are well understood.

Inheritence in general is massively overused by a lot of programmers and it's a good way to obfuscate otherwise readable code. IME mediocre quality C is easier to read and debug than mediocre quality C++, because in the C everything is explicit.

As to abstract interface classes, I don't believe that defining one in any way makes bad design less likely. The case I gave of the "IRender" interface is a case in point, my app is never going to have more than one type of renderer instantiated. Define the interface in the header file. It's just as (im)/mutable as the Interface class and I don't have to pay the overhead of the virtual function calls.

To me interfaces are everything in good design, but Interface classes are not the only way to work with good well defined interfaces. They are a tool nothing more, the way they are used in the Java UI stuff is the right way to use them, declaring them to no benefit is IMO abuse.

 

[Frank]

Agreed. As long as the documentation is good (technical) enough, and/or you can see and step through the source code of the libraries while debugging.

Then again, that's "RTFM!" once again.

I would really like a mechanism, that wouldn't only limit the function declarations (methods/properties etc), but that would also limit the bounds and logic of the return values for those things. Or, something!