I'm writing a cross-platform application and need to pass across argc and argv from Objective-C in Xcode to my generic argument handler class in C++. I have a global pointer to this handler class which I set with a new command, but because I can't do new in Objective-C I'm trying the following:
I have a header file called MacCommandLineArgs.h which contains only the following:
static int cmdlArgc = 0;
static const char** cmdlArgv = NULL;
I then set these from within main.m:
int main(int argc, char *argv[])
{
cmdlArgc = argc;
cmdlArgv = (const char**)argv;
return NSApplicationMain(argc, (const char **)argv);
}
Once the Objective-C++ section of the application has been entered, I try to read back these global variables in order to pass them to the pure-C++ class:
int argc = cmdlArgc;
const char** argv = cmdlArgv;
globalCommandLineArgs = new CCommandLineArgs(argc, argv);
When stepping through with the debugger, cmdlArgc and cmdlArgv show up as valid data but argc and argv are still 0 and NULL after the assignment. What am I doing wrong here?
You don't show how cmdlArgc and cmdlArgv are declared; it's surely in a header file, but what does it look like?.
Nothing outside of main.m will have access to those variables as they have been defined static, which leads me to wonder why you aren't getting linker errors. I have concluded that the declaration of the of cmdlArgc and cmdArgv is something like this:
int cmdlArgc;
const char** cmdlArgv;
rather than this:
extern int cmdlArgc;
extern const char** cmdlArgv;
So every implementation file that includes the header will get their own copy, which is why it's 0/NULL.
The solution is to drop the use of static in main.m and start using extern in the header.
However it's still an ugly pattern and I would think the very best solution is to rename main.m to main.mm and initialise CCommandLineArgs in main(), which is both clean and simple.
when using the Google Test Framework I can have the following code compile, despite there being barewords undefined symbols passed as arguments to TEST.
#include <gtest/gtest.h>
TEST(faketestfixture,faketestname){
ASSERT_EQ(1,1);
}
int main(int argc, char** argv){
testing::InitGoogleTest(&argc,argv);
return RUN_ALL_TESTS();
}
Why/how does this compile? What magic are they using?
I began to peek around the source, but quickly realized I was out of my depth and don't even know where to start.
TEST is a preprocessor macro, and its areguments are not identifiers, the TEST macro just uses them as building blocks to generate code. In this case it generates the class called faketestfixture_faketestname_Test with the method called TestBody. The actual body of that method is what you supply in curly brackets after the TEST macro invocation. So the generated code looks approximately this way:
class faketestfixture_faketestname_Test : public testing::Test {
public:
void TestBody();
// ... more stuff ...
}
void faketestfixture_faketestname_Test::TestBody() {
// This is the test body you supplied.
ASSERT_EQ(1,1);
}
So that's relatively simple. The real magic is in how it all is hooked together and invoked. :-)
WinMain is a function that 'replaces' the default main entry point 'main'.
The user can then define its main entry point like
int WINAPI WinMain(...) { }
How is this kind of encapsulation done?
Well, most likely, at some point it looks like this:
int main() // This must be defined somewhere in windows.h
{
return WinMain(...);
}
Question: How can I accomplish such an encapsulation of my own, which then calls WinMain? Note: The library which I made is a DLL, so it will look like this:
// This is the minimal code for the application which uses 'MyLibrary'
#pragma comment(lib, "MyLibrary.lib")
include "MyLibrary.h"
void Main(MyCustomParameter *params)
{
// Write user code here
}
The problem however is, that the DLL doesn't 'know' the Main() function and therefore throws an 'unresolved external symbol' compile error. So how can I encapsulate it like this?
You have to decide on a signature of your custom main function and declare it as "extern" (extern "C" in case of C++). Then, application code will have to define that function and link against your static library that has the actual _main entry point. For example:
extern "C" int my_main(int argc, char *argv[]);
int main(int argc, char *argv[])
{
return my_main(argc, argv);
}
Actually, the real entry point is neither main nor WinMain. The real entry point is one of wWinMainCRTStartup, WinMainCRTStartup, wmainCRTStartup, and mainCRTStartup. But they're not defined in Windows.h, they're part of the CRT. You can see their code in <VS installation folder>\VC\crt\src\crtexe.c. They each do some initialization and then call one of wWinMain, WinMain, wmain, and main, respectively.
As mentioned by someone else you can override the entry point with the /ENTRY switch, but you still can't have custom parameters, which is the whole reason you want to do this in the first place.
The linker default entry point name is "main".
You can override the default to start with any function you want.
/ENTRY (Entry-Point Symbol)
I need to temporarily put a main() function in my object to test alternate functionality (beyond a simple unit test), but I keep having to comment out my main() function to run my unit tests.
Is there a #define _KEYWORD_ for CxxTest to allow this to happen automatically?
You simply need to encapsulate the offending code with a compiler directive based on the definition of the CXXTEST_RUNNING keyword.
For example:
class myClass {
public:
myClass () {}
};
#ifndef CXXTEST_RUNNING
int main (int argc, char *argv[]) {
// Temporary runner. Typically deleted upon completion
// of alternate functionality added later in the project.
}
#endif
In this case, when using the CxxTest framework the main() function will be ignored in favor of the main() created by the testing framework. Otherwise, the main() function you have provided will be used.
In order to ensure that some initialization code runs before main (using Arduino/avr-gcc) I have code such as the following:
class Init {
public:
Init() { initialize(); }
};
Init init;
Ideally I'd like to be able to simply write:
initialize();
but this doesn't compile...
Is there a less verbose way to achieve the same effect?
Note: the code is part of an Arduino sketch so the main function is automatically generated and cannot be modified (for example to call initialize before any other code).
Update: ideally the initialization would be performed in the setup function, but in this case there is other code depending on it which occurs before main.
You can use GCC's constructor attribute to ensure that it gets called before main():
void Init(void) __attribute__((constructor));
void Init(void) { /* code */ } // This will always run before main()
You can make the above very slightly shorter by giving "initialize" a return type, and using that to initialize a global variable:
int initialize();
int dummy = initialize();
However, you need to be careful with this, the standard does not guarantee that the above initialization (or the one for your init object) takes place before main is run (3.6.2/3):
It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done before the first statement of main.
The only thing that is guaranteed is that the initialization will take place before 'dummy' is ever used.
A more intrusive option (if it's possible) might be to use "-D main=avr_main" in your makefile. You could then add your own main as follows:
// Add a declaration for the main declared by the avr compiler.
int avr_main (int argc, const char * argv[]); // Needs to match exactly
#undef main
int main (int argc, const char * argv[])
{
initialize ();
return avr_main (argc, argv);
}
At least here you're guaranteed that the initialization will take place when you expect.
Here's a somewhat evil method of achieving this:
#include <stdio.h>
static int bar = 0;
int __real_main(int argc, char **argv);
int __wrap_main(int argc, char **argv)
{
bar = 1;
return __real_main(argc, argv);
}
int main(int argc, char **argv)
{
printf("bar %d\n",bar);
return 0;
}
Add the following to the linker flags: --wrap main
eg.
gcc -Xlinker --wrap -Xlinker main a.c
The linker will replace all calls to main with calls to __wrap_main, see the ld man page on --wrap
Your solution in simple and clean. What you can additionally do is to put your code in anonymous namespace. I don't see any need to make it better than that :)
If you are using the Arduino environment, is there any reason you can't place it in the setup method?
Of course, this is after the Arduino-specific hardware setup, so if you have such low-level stuff that it really has to go before main, then you need some constructor magic.
UPDATE:
Ok, if it has to be done before the main I think the only way is to use a constructor like you already do.
You can always make a preprocessor macro of it:
#define RUN_EARLY(code) \
namespace { \
class Init { \
Init() { code; } \
}; \
Init init; \
}
Now this should work:
RUN_EARLY(initialize())
But it's not really making things shorter, just moving the verbose code around.
You can use the ".init*" sections to add C code to be run before main() (and even the C runtime). These sections are linked into the executable at the end and called up at specific time during program initialization. You can get the list here:
http://www.nongnu.org/avr-libc/user-manual/mem_sections.html
.init1 for example is weakly bound to __init(), so if you define __init(), it will be linked and called first thing. However, the stack hasn't been setup, so you have to be careful in what you do (only use register8_t variable, not call any functions).
Use static members of classes. They are initialized before entering to main. The disadvantage is that you can't control the order of the initialization of the static class members.
Here is your example transformed:
class Init {
private:
// Made the constructor private, so to avoid calling it in other situation
// than for the initialization of the static member.
Init() { initialize(); }
private:
static Init INIT;
};
Init Init::INIT;
Sure, you put this in one of your your header files, say preinit.h:
class Init { public: Init() { initialize(); } }; Init init;
and then, in one of your compilation units, put:
void initialize(void) {
// weave your magic here.
}
#include "preinit.h"
I know that's a kludge but I'm not aware of any portable way to do pre-main initialization without using a class constructor executed at file scope.
You should also be careful of including more than one of these initialization functions since I don't believe C++ dictates the order - it could be random.
I'm not sure of this "sketch" of which you speak but would it be possible to transform the main compilation unit with a script before having it passed to the compiler, something like:
awk '{print;if (substr($0,0,11) == "int main (") {print "initialize();"};}'
You can see how this would affect your program because:
echo '#include <stdio.h>
int main (void) {
int x = 1;
return 0;
}' | awk '{
print;
if (substr($0,0,11) == "int main (") {
print " initialize();"
}
}'
generates the following with the initialize() call added:
#include <stdio.h>
int main (void) {
initialize();
int x = 1;
return 0;
}
It may be that you can't post-process the generated file in which case you should ignore that final option, but that's what I'd be looking at first.
There is how I perform pre-main coding.
There are sever init sections executed before main, refers to http://www.nongnu.org/avr-libc/user-manual/mem_sections.html initN sections.
Anyhow, this only works on -O0 optimization for some reason. I still try to find out which option "optimized" my pre-main assembly code away.
static void
__attribute__ ((naked))
__attribute__ ((section (".init8"))) /* run this right before main */
__attribute__ ((unused)) /* Kill the unused function warning */
stack_init(void) {assembly stuff}
Update, it turns out I claimed this function is unused, leading to optimize the routine away. I was intended to kill function unused warning. It is fixed to used used attribute instead.