Where are you including io.cpp?

Stupid question, but you made sure that IO.cpp is getting compiled and linked as part of the project?

haha gmta

For what it's worth, linker errors of this type mean that a function was defined (such as in a header), but the linker didn't find their definition (i.e., implementation) anywhere. That implementation can't be in a header usually (unless it's a class member), or you'll have the opposite problem of double definition.

In practice, the error is usually caused by the definition's signature being slightly different, or by forgetting to link with the .cpp file where the function resides. You don't appear to be suffering the former problem.

So Semck, Mapu, including IO.h also includes IO.cpp, right?

That being said, I feel you are is basically addressing the issue. If I actually

# "include IO.cpp"from Reg_script.cxx, I get a different error (double definition of "reader", an error that somewhat makes sense in that context)

Basically, I think in standard c++ doing #include "IO.h" also automatically includes IO.cpp, but I'm not sure that it is being done properly because I'm forced to use the stupid cmake wrapper. I feel I need to let cmakelists.txt know IO.cpp is included, somehow. I just don't know how.

I do not know MSVisual or cmake or ITK, but I see a few things that seem odd or wrong or just unnecessary.

Why do you have the typedef lines in main when they are already in IO.h?

In Read_Raw_Data(), the second parameter is char * filename, but then instead of passing filename into SetFileName(), you pass in argv[1] which I wouldn't expect it to know about. Seems like IO.cpp wouldn't compile, which could then lead to your link error.

No, #include "io.h" does not automatically include IO.cpp. What '#include "io.h"' does is literally place the contents of "io.h" at that point in your file. CPP makes NO connection between io.h and io.cpp. The similarity in names is for your own convenience, but it has no semantic significant to C++.

Compilation occurs in two steps. First, a compiler compiles each .cpp file (not each .h file). The .h files let a given file know that a particular function exists, and that it will be implemented in some (probably different) .cpp file. The compiler generates a .obj file for each .cpp file it is instructed to compile. So for example, reg_script.obj.

The linker then takes all the .obj files and puts them together into an executable. At this point, it expects to find and sort out all the different functions that were declared to exist somewhere "out there" at the compilation stage. If it doesn't find one, it gets very upset. (It has experienced a lot of losers over the years, and it never believes the check is in the mail).

So if you don't tell the compiler to compile io.cpp, and then tell the linker to include io.obj when linking, this will occur, and you will get that error.

And yes, you will get different errors if you #include a .cpp, most likely. Sadly, I don't know how to use cmake. I'll go try to find out though.

Maybe try an add_directory so you get all the source files in that directory? (I'm not sure that works. I know nothing about cmake, as noted).

OK, so you're both saying I should #include "IO.cpp," and then fix the errors that come up there? I'll let you know what happens.

Alderian, you are allowed to change the name within the local environment of a function. argv[1] is a global variable, and when it gets passed to the function I've redefined the name. As for typedef, that's a good question.

No, they are both saying not to #include io.cpp. you don't #include cpp files, only .h. you have to add it to your make file to compile it. You have to add all cpp files to your make file in order for them to be compiled into an obj file so the linker can link to it.

#include is a pre-compiler directive. You can think of it as a replacement. as semck said, #include is the same as copying the contents of the file in peace of the #include line. Link errors are post compilation.

Just a tip as I don't think you're aware, if you put "using namespace std;" after your includes, but before the main, you won't have to ever use "std::".

It saves some time and makes code a bit clearer, for me at least.

Argv and argc are not global. Their scope is the main() function, just like any other function parameter.

I dint think ip.cpp will compile with the reference to argv in it. If it does, then I've learned something today. But even if it does, its bad style because the implied scope of argv is the main function and you are passing it into another function using the parameter name filename. So continue to use filename in that function si that its clear that its the input parameter your using.

What if you want to call this function with a different filename than the one passed in as the 2nd parameter on the command line? It should still do its job without knowledge of the command line parameters.

I dint think ip.cpp

Should be
I don't think io.cpp

And for what its worth, this isn't an object oriented program. This could have just as easily been a c program other than the cpp-specific constructs like templates.

Not that that's a bad thing (for a program this small, oo might be overkill), I just figured, since I was sharing my thoughts on the program, you'd want to hear (or read) all of them ;-)

@YJ, to clarify, I was saying that in the Read_Raw_Data() function (or method or routine or whatever you want to call it), the parameter being passed into SetFileName() should be filename, not argv[1]. That has to be fixed before IO.cpp will compile.

But as others have said, the real problem is that you need IO.cpp to be compiled as part of your cmake script or whatever that is. But I don't know anything about cmake so I can't help you with that part.

" you have to add it to your make file to compile it"

THAT is the step I forgot about (but apparenlty still suspected was the issue). Thanks Phil.

"using namespace std"

I know, but I think I will be using a different namespace after more code is written, and I can only use one, right?

"Argv and argc are not global."

Of course, thanks for the correction. I tend to throw around terms that I don't 100% know what they mean, I'm not a good programmer.

"I dint think ip.cpp will compile with the reference to argv in it"

It definitely won't. And thanks, Alderian, I see your point now. I just didn't realize I had made that error in the code.

Anyways, somebody more familiar with cmake has given me some links on how to compile it with IO.cpp included. Thanks for the tips, guys.

"I know, but I think I will be using a different namespace after more code is written, and I can only use one, right?"

No, you can use any number of namespaces. All that "using" does is dump all the names in a given namespace into the global namespace (for that file). You can do this for whatever namespace you want. Of course, if two conflict (have functions with the same name, say) you'll still have to resolve that.

Never put a "using" statement in a header, because then it will automatically be applied in every source file that includes that header, which may be undesireable.