Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nadaka]

A header file is for declaration of publicly accessible functions. It essentially provides the interface for your class so that you could distribute it as a binary object and people could still build code that references its methods.

so, if the header file is ONLY for publicly accessible functions, I can't put private class variables in it?  :confused:

Its c++, you can poop anywhere you want, it just makes a mess. You can even put your whole code in the .h if you want to. Or you can not use .h files and just include .cpp.

[Mego]

A header file is for declaration of publicly accessible functions. It essentially provides the interface for your class so that you could distribute it as a binary object and people could still build code that references its methods.

so, if the header file is ONLY for publicly accessible functions, I can't put private class variables in it?  :confused:

Its c++, you can poop anywhere you want, it just makes a mess. You can even put your whole code in the .h if you want to. Or you can not use .h files and just include .cpp.

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.

[Valid_Dark]

ok, yeah, I need to start doing muli file shit, because right now I have a few 3000+ line projects that are all in one file, and it's starting to get annoying.

[kaijyuu]

Multiple .cpp files confused me for the longest time. My first big project just had 1 .cpp file (for the main function) and everything else was in .h files.

[alway]

Though some of the things mentioned will cause linker problems in Visual Studio; particularly doing an 'include' for .cpp files. It's why I had everything in .h files except main all the way up until I finally figured it out. By which point I was doing 3D with DirectX.

Which is rather problematic, as your programs' include dependencies then have to be a tree structure w/o loops or linker errors appear everywhere. Which is also why I started keeping a folder called 'Teh box of programming lolz.'

[Siquo]

For me, I think the biggest thing about .h files is the size of the class. C++ allocates memory based on how big it thinks your object will be, and it only knows your .h class. For pointers, this doesn't matter, as they're "pointer-sized".

So in order to make an array of Objects, you must include Object.h where all Objects' members are defined. Functions can be declared but I think that's optional (although I always delcare all functions in the .h anyways). For pointer-members to work, a simple empty declaration at the beginning is enough.

For instance:

Code: [Select]

Mug.h:
//<-- no includes! Usually the only one needed here is the class we're extending from.
class Liquid; // empty class!

class Mug {
public:
  Liquid* contents;

  void drinkContents();
}
------
Mug.cpp:
#include "Mug.h"    //<-- we'll be using stuff declared here
#include "Liquid.h"  //<-- we'll be using stuff declared in here as well

void Mug::drinkContents(){
  if(contents){
    contents->drink();   //<-- and here we call an actual member function.
  }
}

Non-pointer-members are trickier, because their size is added to the size of the container object. Here you should be careful not to create circles, or everything goes to hell.
Moral of the story: .cpp files should include .h files, and .h files should include the least possible number of .h files.

[alway]

So today I learned something. DirectCompute is terrible. It's integrated with DirectX's hlsl; that means metric craptons of initialization to pass any data to or from it. Its feature set is pretty much a more limited subset of both CUDA and OpenCL, while simultaneously being harder to use what is there.

It has terrible documentation, resulting in all sorts of little hidden pitfalls. For example, an RWTexture, from which the GPU can read and write, effectively the preferred means of passing in data to DirectCompute, can be set as types like 'float' 'int' 'float4' 'int4' 'uint4' and so on. However, you can't actually read from any types which aren't single values of size 32 bits; which means float or int. You can, however, write to the other types. And due to it being pretty terrible, good third party material is nearly nonexistent. The only real tutorial microsoft provides is in the form of about 3 hours of 20 minute videos. Because everyone loves to listen to hours of people reading documentation rather than having searchable text tutorials with clearly denoted sections and sample code.

In summary, use OpenCL.

[Valid_Dark]

well yeah, OpenGL > DirectX in just about every way.

and Mego, I had a question, can you explain what you meant by

#ifndef FOO_H_INCLUDED // Guard word, used to make sure that this code only gets included once in any compilation target, to prevent multiple definition errors
#define FOO_H_INCLUDED

[kaijyuu]

There's also a #endif later, which is important.

Basically that little block of code prevents multiple declaration errors. The compiler will skip trying to define something twice if it comes across the same header twice. Anything between the #ifndef and the #endif gets skipped if the word is already declared (which is the first thing that happens after the #ifndef).

[Skyrunner]

Some compilers support #pragma once, which I think does the same thing.

[Valid_Dark]

There's also a #endif later, which is important.

Basically that little block of code prevents multiple declaration errors. The compiler will skip trying to define something twice if it comes across the same header twice. Anything between the #ifndef and the #endif gets skipped if the word is already declared (which is the first thing that happens after the #ifndef).

but i'm guessing the "FOO_H_INCLUDED" gets replaced with something, ya?  ...but what?

I think i'm gonna go the  #pragma once route, and see if my compiler supports it.

[kaijyuu]

Well it just needs to be a unique word. So yeah, replace it with whatever, so long as it won't conflict with any variable definitions or other headers or whatever.

[Skyrunner]

Usually, it's named what your file is named.
So if your header is calculating.h, write
#ifndef CALCULATING_H
#define CALCULATING_H

...

#endif //CALCULATING_H

[Valid_Dark]

good to know,
also, when/where should I initialize class objects?
I'm used to initializing them with the class definition.

class myclass
{
     public:
     myclass();

     private:
     int var;
}myObject;

is that bad coding would you say? and it should still work that way, yeah?
also, what are the rules of calling functions from a different source file?

[kaijyuu]

Yeah, that's bad coding since it's making a global variable, which isn't good outside of a few things. Instead, you'll want to declare instances of objects when you need them, similar to how you'd declare ints or whatever. So if you only need to use the object in a single function, just declare it within the function as a local variable. Stuff like that.

also, what are the rules of calling functions from a different source file?

You'll need to define the function first (generally done in headers). The actual code will be in another .cpp file, but the function's name and arguments would be defined so the compiler knows it actually exists.

So in a hypothetical MyFunction.h header, you'd have something like this:

void MyFunction(int);


And within the MyFuction.cpp file, you'd have this:

void MyFunction(int Value)
{
//DO STUFF
}


And you'd include MyFunction.h in any .cpp file where you want to use the function.