I'm just learning c++. I have a main.cpp unit which has a lot of stuff in it already, and I just want to build a quick little testMain.cpp unit that will test a couple of things.
Basically I want to trick the compiler (xCode) into ignoring the real main function for a minute. I could
Rename the main() function inside main.cpp to mmain() temporarily.
Remove the reference to main.cpp in my project temporarily.
Comment out the main() method in main.cpp temporarily.
All these seem pretty clunky. There has to be an easier way. I suspect this is a common thing people do. How do you do it?
Another solution would be to separate the code into multiple files, have most of the logic in one file, have the real main in another and the test main in a third, you compile and link either the first and second or first and third files but never all three together.
Your option 2 is the most common strategie, and from my understanding also the cleanest.
After all, your test application will most likely not share the same command line interface, and that is usually about the only thing which should (of at all) be located in the main function or file.
If your main.cpp contains significantly more than just the entry point, you should immediately start thinking about how to distribute that logic into the modules you already have.
Use a macro.
Option 1: Use a macro to include/exclude entire files:
main.cpp:
#ifdef USE_REAL_MAIN
int main(int argc, char* argv[]) {
...
}
#endif
testMain.cpp
#ifdef USE_TEST_MAIN
int main(int argc, char* argv[]) {
...
}
#ENDIF
build file:
gcc -DUSE_REAL_MAIN
gcc -DUSE_TEST_MAIN
Option 2: Use a command-line macro to rename main:
main.cpp:
int realMain(int argc, char* argv[]) {
...
}
testMain.cpp
int testMain(int argc, char* argv[]) {
...
}
build file:
gcc -DrealMain=main
gcc -DtestMain=main
Note this is probably the least attractive option because it breaks the convention of macros having UPPER_CASE names and means the real entrypoint of your program is non-obvious to someone who hasn't seen the build script. It also means the program simply won't compile (as there's no main function) without your custom build script either.
Option 3: Have a new common main with the #ifdef directives instead:
main.cpp
#include "realMain.h"
#include "testMain.h"
int main(int argc, char* argv[]) {
#ifdef USE_TEST_MAIN
return testMain( argc, argv );
#else
return realMain( argc, argv );
#endif
}
build file:
gcc -DUSE_REAL_MAIN
gcc -DUSE_TEST_MAIN
I think this is my preferred option because it's almost self-documenting and makes it clear to another programmer how to get it to work without needing your custom build script.
Related
I have a C program that I need to interface with a C++ library (ROS). Normally, it's not too difficult to interface C code with C++ code with a wrapper using extern "C" and using the C++ compiler to link, but I've never had to do it where main was in the C portion.
The C++ FAQ indicates that this is a bad thing:
Here are some high points (though some compiler-vendors might not require all these; check with your compiler-vendor’s documentation):
You must use your C++ compiler when compiling main() (e.g., for static initialization)
But I see another source saying it should be okay these days:
At one time, most C++ compilers required that function main be compiled by the C++ compiler. That requirement is not common today, ...
Why would it matter whether main is in the C portion or the C++ portion? How much trouble would I be in if I try to link code where it's in the C portion using common linkers today (mainly GCC's and Clang's)?
One easy way to work around this is to rename your C main() and call it from a new C++ main()
As in:
// in ypur current C main module
int my_c_main(int argc, char* argv[]) /* renamed, was main() */
{
/* ... */
]
// in a c++ module...
int main(int argc, char* argv[])
{
extern "C" int my_c_main(int argc, char* argv[]);
// if your c main() requires environment variables passed in envp,
// You can allocate space for strings and an array here and pass
// the environment variables you'll need, as the third parameter
// to my_c_main(), or pass environ, if your system has
// it defined in unistd.h
return my_c_main(argc, argv);
}
I am a little bit new to cpp. And all the concepts of 'includes' tho are important are pretty new and vague forme. I have a few questions which are related to my main question . The main question is:. I have a program which is a file containing 'main' and other 5 classes let's call it 'PROG'. I put them all in one file using no h files at all. The program is running and all is good. The point is, I now have 'test file ' which should test my program. Test file is separated to h file and cpp file. Is there any way to run everything without changing my program 'PROG'?? I don't want to create h files to my 'PROG' . The problem is, the test file uses a few of the claseess written the program 'PROG'. I thought about writing 'includes' cpp in the test file and putting 'pragma once'. I don't know why it doesn't work. Doesn't pragma once work for ' cpp includes'??
Or basically can anyone answer the general question. Which is in short:. You have a file containing main and classes (which all in cpp file with no h file) . And you want to run it with another file (cpp+ h) but both files use each othrr. Which makes a circular use. Is there a way to run it ?
You might be able to write tests, however they will be run at an unspecified time either before or after your program runs, so won't be able to access std::cout etc. If your program uses any static objects, you won't be able to do this.
It will be much easier to move your main into a main.cpp that #includes definitions of your classes, and compile a separate test_main.cpp that instead runs your tests.
As a sketch of the former
class TestFailure{};
class RunAtStartup
{
template<typename Func>
RunAtStartup(Func f) { f(); }
}
extern double function_to_test(int arg);
static RunAtStartup run_function_to_test([]{
// arrange
int param = 0;
// act
double res = function_to_test(param);
// assert
if(res != 1.0) throw TestFailure();
});
Does this help?
PROG:
class C {
void f();
}
#ifndef TEST
void C::f() {
// implementation
}
#endif // TEST
TEST:
#define TEST
#include "main.cpp"
// Your test code here can have instances to class C
C c;
c.f();
But take cpp/h approach as anyone recommends, which is everywhere.
I'd highly recommend using headers, but if you really don't want to modify your original file, you can #include "main.cpp" from your test file and redefine the main symbol during the inclusion. This allows you to create your own main method for the test program.
In test.cpp:
#define main real_main
#include "mymain.cpp"
#undef main
int main(int argc, const char** argv) {
std::cout << "wah" << std::endl;
int fakeargc = 1;
const char* fakeargv[fakeargc] = { "hoo" };
real_main(fakeargc, fakeargv);
}
In main.cpp:
#include <iostream>
int main(int argc, const char** argv) {
std::cout << "hello world " << argv[0] << std::endl;
return 0;
}
I'm developing an OS kernel as a hobby and I already have a library that replaces the standard library in both hosted and freestanding environments. Naturally it provides the entry point that does the necessary set up and calls main().
In hosted environment it seems that it doesn't matter if the signatures of the main() declaration and in the actual main() definition doesn't exactly match. However, once I add the -ffreestanding compilation flag, the linker can no longer resolve such reference. See the minimal example below:
start.cpp
int main(int argc, char *argv[], char *envp[]);
extern "C" void _start()
{
main(0, nullptr, nullptr);
}
main.cpp
int main()
{
return 0;
}
Command line:
clang++-6.0 -nostdlib -ffreestanding start.cpp main.cpp
It seems that this behavior is specific to Clang since GCC 7.3.0 compiles this example successfully.
My question is how the above example is allowed and working in general and whether the issue I'm experiencing is a Clang bug.
Update 1:
Turned out that the solution to this is to add __attribute__((weak)) to the declaration of main(). However, it would be nice if someone could explain in more detail how does this usually work with main().
Update 2:
Apparently marking main() as a weak symbol makes it possible to link without main() at all which is obviously not how it normally works (given all the other "undefined reference to main" questions on SO). So if main() is not usually a weak symbol how does it really work?
Update 3:
Turns out that a weak symbol is not a solution at all, because when used with -ffreestanding it only hides the fact that the int main(int argc, char *argv[], char *envp[]) is never resolved and the actual int main() is not called from _start() at all. In hosted environment, however it's still called as usual. This seems more and more like a Clang bug.
I get this error in a C++ file where I am writing some tests:
error: no member named 'Session' in namespace 'Catch'
testResult = Catch::Session().run(test_argc, test_argv);
~~~~~~~^
Looking at the catch.hpp single header file, I noticed that the code that should implement the Session() member function is greyed out, probably because of an #ifdef somewhere, which I cannot find.
Is there any macro to set to use the Session class?
Catch versions: 1.5.3 and 1.5.6.
Reference: https://github.com/philsquared/Catch/blob/master/docs/own-main.md
You're attempting to call the constructor of Catch::Session from a file where you're not defining your own main to execute. According to the documentation on defining your own main, there is supposed to be only one instance of Catch::Session:
Catch::Session session; // There must be exactly once instance
It's likely Catch is preventing construction of Catch::Session in translation units where it can't be used in a custom main definition (since that's where it's supposed to be used), to prevent exactly the mistake you've made from compiling.
Reference to https://github.com/catchorg/Catch2/blob/master/docs/own-main.md
You can only provide main in the same file you defined CATCH_CONFIG_RUNNER.
#define CATCH_CONFIG_RUNNER
#include "catch.hpp"
int main( int argc, char* argv[] ) {
// global setup...
int result = Catch::Session().run( argc, argv );
// global clean-up...
return result;
}
I have a small test project with the following layout:
testmain.cc
Foo\
|--FooClass1_test.cc
|--FooClass2_test.cc
Bar\
|--BarClass1_test.cc
|--BarClass2_test.cc
In the *_test files I have defined tests along the lines of
TEST(Foo, foo_func1_works)
{
EXPECT_EQ(42, the_answer);
}
And testmain.cc contains only:
#include <gtest/gtest.h>
int main(int argc, char* argv[])
{
testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}
I can see that the TEST macros generate self-registering classes which RUN_ALL_TESTS will know about, but how is this code linked? Nothing references the tests defined in the .cc files, no includes etc. Why does the linker not throw this code away? I am compiling the project with MSVC 2010.