- Forum
- Windows Programming
- Loading code from an external cpp file
Loading code from an external cpp file
closed account (NUj6URfi)
If I have a cpp file that is too big, I could break it up, but how could I compile them together?
Last edited on
As long as the appropriate boilerplate is present in both files, and you don't split it in the middle of a function (or other compound thing), there's no reason you can't split it anywhere you like.
Compiling works the same way as before. List the files and the output. If you just one one object file for the sources, there are a number of ways to combine them, but the following should work with GCC:
g++ -c foo1.cpp foo2.cpp -o foo.o
Hope this helps.
Compiling works the same way as before. List the files and the output. If you just one one object file for the sources, there are a number of ways to combine them, but the following should work with GCC:
g++ -c foo1.cpp foo2.cpp -o foo.o
Hope this helps.
The other part of the "trick" is that functions defined in (that is, the implementaton is in) (e.g.) foo1.cpp which are used in foo2.cpp need to be forward declared in foo1.h to #include can be used to let foo2.cpp know what's up.
Andy
@Duoas -- I mostly use VC++ on Windows, so don't know GCC that well. But would
g++ foo1.cpp foo2.cpp -o foo
be right for a basic, single-line compile and link to foo (as executable) -- you don't use .exe with executable on Linux, do you?
Andy
@Duoas -- I mostly use VC++ on Windows, so don't know GCC that well. But would
g++ foo1.cpp foo2.cpp -o foo
be right for a basic, single-line compile and link to foo (as executable) -- you don't use .exe with executable on Linux, do you?
Last edited on
Yes, the .cpp files should both #include the .hpp file so that everything is properly forward-declared. Some systems also have a "fooInt.hpp" header which is for stuff defined internally across .cpp files -- that is, for stuff that the library user has no need to see.
Yes, that command line is correct. It will compile all the listed source files and link them into the "foo" executable -- which on Windows will have an .exe extension and on *nix will have no extension at all.
The -c flag says "compile only (but do not link)" so the command I gave will make "foo.o" out of foo1.cpp and foo2.cpp. The object file format between GCC and VS are different, hence the difference between .o and .obj file.
Yes, that command line is correct. It will compile all the listed source files and link them into the "foo" executable -- which on Windows will have an .exe extension and on *nix will have no extension at all.
The -c flag says "compile only (but do not link)" so the command I gave will make "foo.o" out of foo1.cpp and foo2.cpp. The object file format between GCC and VS are different, hence the difference between .o and .obj file.
closed account (G309216C)
Either you can make separate DLL (Dynamic Link Libraries) that can be called via using
Or creating a new cpp file with a specific function then add the function prototype to the main (Entry Point Cpp file).
I am not sure if the second method works on other compilers except Visual Compilers. Personally if the project is above 8,000+ lines use the first suggestion else use second suggestion.
After creating the actual DLL file you can reference it on build using VS options which allow the DLL to be dropped to the Build folder (Debug,Release).
Or you can embed the DLL as a resource (BINARY) then drop it to the Hard drive directly or even execute it directly to memory therefore reducing the dependency rates.
GetProcAddress(GetModuleHanldeW(L"DLLName.dll"),"FunctionName");Or creating a new cpp file with a specific function then add the function prototype to the main (Entry Point Cpp file).
I am not sure if the second method works on other compilers except Visual Compilers. Personally if the project is above 8,000+ lines use the first suggestion else use second suggestion.
After creating the actual DLL file you can reference it on build using VS options which allow the DLL to be dropped to the Build folder (Debug,Release).
Or you can embed the DLL as a resource (BINARY) then drop it to the Hard drive directly or even execute it directly to memory therefore reducing the dependency rates.
Topic archived. No new replies allowed.