I have been writing Java for a long time using Eclipse, now trying to switch to C++ in Visual Studio. From Eclipse/Java I know such auto-complete features: I write
bar = Foo.valueOf(x);
bar.doSomething(y, z);
and Eclipse offers me both to import whatever Foo I might mean, and declare bar as local variable, field, or parameter. Or create the function doSomething() with the appropriate signature, auto-adding missing imports to Foo. I am missing a corresponding feature on Visual Studio 2015, which does for example
add the corresponding #include and #pragma comment(lib, statements,
add these statements in a clear order, so that they work as expected (something like organize imports),
add namespace statements
declare variables, fields, and parameters on click/keypress
create function bodies, adding the corresponding foreward declarations to the respective header files, adding missing includes required by the declaration
…
The only things that I found so far is the “add class” dialog. When writing an unknown function name, right clicking and choosing “quick actions and refactorings” → Create declaration / definition, a window opens with the text
int main(int argc, char * argv[]);
but it does not create a definition for that function.
Are there some better “save me typing work” functions available in Visual Studio 15, and if yes, how can I benefit from them? Is there another way I could go, such as writing the C++ program (Windows API) in an other IDE (are there any for Winapi C++ which do better?)
Resharper by JetBrains does what you are asking for more or less. It will notice an error in your code, whether it being that something wasn't fully initialized, or something that you needed to include, or a host of other things.
It is not free though, but you can try it on a 30 day trial.
I don't know of an IDE that supports winapi functions like you're asking though. I think you'll just have to pick your favorite IDE and get used to it.
Related
Is it possible to dynamically create __declspec(dllexport)'ed functions without having the preprocessor involved in MSVC 2015?
I'm creating a DLL plugin-creation toolkit for some kind of measurement software and want to make the later client-programmer being able to add some kind of "extra-features" to the plugin in the DllMain, e.g.:
// Create a new instance of the custom driver
MyPluginDriver *myPluginDriver = new MyPluginDriver();
// Assign it to the core DLL
pluginCore.addDriver(myPluginDriver);
For each of this addDrivercalls, the DLL later has to provide a callback function, whose name can be freely chosen. The main app expects the names of those functions getting passed by request in another callback.
So, what would be the 'best practice' for generating those extern "C" functions dynamically whithout #define's and stuff?
Maybe some kind of Lambda way?
EDIT:
I think I've forgot to mention that it's a commercially available measurement software for which I'm writing that PDK. It's a fixed interface (and a fairly complex one, too) of hard-coded and expected function names by the app for the general callbacks. There's only that particular callback expecting some function names to call for measurement cycles which is relevant here.
I was looking at using SetDlgItemInt and out of curiosity I changed it to SetDlgItemDouble to see if this was also a function.
SetDlgItemDouble has been recognised as a function and when I hover over it, it displays BOOL SetDlgItemDouble(HWND hDlg, int id, double d) but when I go to compile it gives me the error: error C3861: 'SetDlgItemDouble': identifier not found, even with argument-dependent lookup.
I've googled the term SetDlgItemDouble and it gives me a few links mainly in a far east language but nothing directly with MSDN and also searching this site nothing comes back.
So is it a function? If so, how do I use it with visual c++ 2003?
SetDlgItemDouble is not a standard C++ function: i.e. a standards compliant C++ compiler is not required to implement it.
But there's nothing stopping you from implementing it. Or a 3rd party library for that matter.
Your IDE is probably configured to think that the function exists, even if you don't have an explicit #include to the relevant file. Visual Studio does tend to do this (especially for standard C++ library functions that you haven't necessarily #included), in order to attempt to be helpful.
SetDlgItemDouble is not avaialble in MFC or win32. You can try using SetDlgItemInt (or) SetDlgItemText in visual c++. If the intention is to display a double value in any Dialog control, you can use SetDlgItemText and display that value as a string in your Dialog.
I was in class and they were emphasising on the importance of using prefixes to make your code more readable.
As a lazy programmer, I've learnt that there's often a way to macro or automate something to reduce the typing needed. I'm a big fan of hotkeys etc.
Now this got me to wonder , is it possible to create something like a macro (VS 2013 - macro's are deleted from the program) that would write prefixes in declarations for you?
I imagine just being able to write a list like this :
TextBox - txt
BitMap - bmp
Member variable - m_
...
And then next time you'd write a declaration, it would automaticly put in the prefix after you press the space.
Resharper in c# has something similar, where they would basicly update intelisense to do this, so I imagine c++ having something like this aswell?
If not, what langauge should I look into to create this type of code?
Intensive googling unfortunately did not yield the answer.
I'd like to use some C++ code in an Xcode project but I don't understand either language well enough yet to know how to proceed. I've been at the Obj-C for a while and have an app on the app store, but still learning...
The code I want to use has two files with the same name and .h and .c extensions. I would think they correspond to .h and .m files in Obj-C, but they lack the #interface and #implementation structure I'm familiar with. And there's a main.c that I don't know what to do with. It looks like it's the main program - should I try to pull its code out into my primary viewController?
Maybe a link to a good tutorial? Maybe this question's too vague...
FYI - the code I want to use is for calculating sunrise and sunset times, and is located at: http://www.risacher.org/sunwait/
Thanks!
EDIT:
Thanks for the suggestions - I will probably have to do some more learning before I get this. But I made some progress...
In main.c (seems weird to have a file called that...) there is a function(?) like this:
int mainFunction(int argc, char *argv[])
{
// a bunch of function-y stuff
}
It was called main but I changed it to mainFunction to get rid of an error. Now it compiles and I can call it but the compiler warns me thus: warning: implicit declaration of function 'mainFunction' and it crashes after I call it.
Now it compiles and I can call it but the compiler warns me thus: warning: implicit declaration of function 'mainFunction' and it crashes after I call it.
This is because, where you use this function, you do not forward-declare or include the declaration of the function. In your Objective-C code, you should add the following bit of code:
int mainFunction(int argc, char *argv[]);
Also note that the ".c" file extension is C code, not C++. Since Objective-C is a superset of C, you could just as easily change the extension to ".m", and you'd still get the same error since you need this forward declaration. I would strongly recommend familiarizing yourself with both C and C++ code before venturing into the world of Objective-C. If you wish to forgoe learning C++, then at the very least, you should strengthen your C knowledge before going into Objective-C, as the C fundamentals apply.
First of all, if your files have a .c extension, they are almost certainly C and not C++. All you have to do is add them to the project and target and include the relevant .h file in the Objective-C where you call the C functions.
Now the fact that you used to have a function called main() tells us that you had a stand alone program. Every stand alone program has to have a function called main(), it's the entry point for the program. Your Objective-C application will have a function main() already which is why you were getting an error. You can take the approach of renaming the duplicate and calling it but there are a number of pitfalls with that approach.
As you found out, you need a function prototype to stop the implicit declaration warning. This should be
int mainFunction(int argc, char* argv[]);
and should be in a header that you include in the .m file where you want to call it.
In C, certain assumptions are made about the parameters. argc is the number of char*s in argv. argv[0] is conventionally the name of the program as invoked on the command line. So argc must be at least 1 and argv[0] must point to a string. The remaining char*s in argv point to the command line parameters.
Typically, a command line program expects to be able to accept input from the keyboard and display output on the screen. This is done through three file descriptors: stdin, stdout and stderr. Stdin is for input, stdout is for normal output and stderr is for output of error and other 'out of band' messages. Intercepting these file descriptors in a GUI application is non trivial.
I suggest you work through the basics of C to gain an understanding of it. You can probably learn enough to progress your project in a day or two. The classic text is The C Programming Language. It's still one of the best IMHO.
There is a chapter in the Objective-C 2.0 guide here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html#//apple_ref/doc/uid/TP30001163-CH10-SW1
Basically you can mix C++ and objective-C, but there are a couple of pitfalls. It sounds like you may need to learn more about C++ in general before you explore the nuances of objective-C++
Rename sources from .m to .mm, then they become Objective C++. You can instantiate and call C++ classes from Objective C code and vice versa. You cannot, though, derive ObjC classes from C++ classes and vice versa. Also, mind the calling conventions - the global functions in .m files are extern "C" as far as .mm/.cpp files are concerned.
Linking together .mm and .cpp works fine, too.
There are not many tutorials about this unfortunately. I think this has been asked a couple of times in stackoverflow, so searching here will give you some hints. The first pitfall you would want to avoid is, you need to use the ".mm" extension for your obj-c files to enable the c++ extension.
http://www.cocoadev.com/index.pl?CPlusPlusInCocoa
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html
Adding C++ Object to Objective-C Class
http://robnapier.net/blog/wrapping-c-objc-20
One last pointer is, look at opensource projects e.g. chrome to see how they mix up obj-c and C++. Google search is also your friend :).
From what I can tell you can kick off all the action in a constructor when you create a global object. So do you really need a main() function in C++ or is it just legacy?
I can understand that it could be considered bad practice to do so. I'm just asking out of curiosity.
If you want to run your program on a hosted C++ implementation, you need a main function. That's just how things are defined. You can leave it empty if you want of course. On the technical side of things, the linker wants to resolve the main symbol that's used in the runtime library (which has no clue of your special intentions to omit it - it just still emits a call to it). If the Standard specified that main is optional, then of course implementations could come up with solutions, but that would need to happen in a parallel universe.
If you go with the "Execution starts in the constructor of my global object", beware that you set yourself up to many problems related to the order of constructions of namespace scope objects defined in different translation units (So what is the entry point? The answer is: You will have multiple entry points, and what entry point is executed first is unspecified!). In C++03 you aren't even guaranteed that cout is properly constructed (in C++0x you have a guarantee that it is, before any code tries to use it, as long as there is a preceeding include of <iostream>).
You don't have those problems and don't need to work around them (wich can be very tricky) if you properly start executing things in ::main.
As mentioned in the comments, there are however several systems that hide main from the user by having him tell the name of a class which is instantiated within main. This works similar to the following example
class MyApp {
public:
MyApp(std::vector<std::string> const& argv);
int run() {
/* code comes here */
return 0;
};
};
IMPLEMENT_APP(MyApp);
To the user of this system, it's completely hidden that there is a main function, but that macro would actually define such a main function as follows
#define IMPLEMENT_APP(AppClass) \
int main(int argc, char **argv) { \
AppClass m(std::vector<std::string>(argv, argv + argc)); \
return m.run(); \
}
This doesn't have the problem of unspecified order of construction mentioned above. The benefit of them is that they work with different forms of higher level entry points. For example, Windows GUI programs start up in a WinMain function - IMPLEMENT_APP could then define such a function instead on that platform.
Yes! You can do away with main.
Disclaimer: You asked if it were possible, not if it should be done. This is a totally un-supported, bad idea. I've done this myself, for reasons that I won't get into, but I am not recommending it. My purpose wasn't getting rid of main, but it can do that as well.
The basic steps are as follows:
Find crt0.c in your compiler's CRT source directory.
Add crt0.c to your project (a copy, not the original).
Find and remove the call to main from crt0.c.
Getting it to compile and link can be difficult; How difficult depends on which compiler and which compiler version.
Added
I just did it with Visual Studio 2008, so here are the exact steps you have to take to get it to work with that compiler.
Create a new C++ Win32 Console Application (click next and check Empty Project).
Add new item.. C++ File, but name it crt0.c (not .cpp).
Copy contents of C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src\crt0.c and paste into crt0.c.
Find mainret = _tmain(__argc, _targv, _tenviron); and comment it out.
Right-click on crt0.c and select Properties.
Set C/C++ -> General -> Additional Include Directories = "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\crt\src".
Set C/C++ -> Preprocessor -> Preprocessor Definitions = _CRTBLD.
Click OK.
Right-click on the project name and select Properties.
Set C/C++ -> Code Generation -> Runtime Library = Multi-threaded Debug (/MTd) (*).
Click OK.
Add new item.. C++ File, name it whatever (app.cpp for this example).
Paste the code below into app.cpp and run it.
(*) You can't use the runtime DLL, you have to statically link to the runtime library.
#include <iostream>
class App
{
public: App()
{
std::cout << "Hello, World! I have no main!" << std::endl;
}
};
static App theApp;
Added
I removed the superflous exit call and the blurb about lifetime as I think we're all capable of understanding the consequences of removing main.
Ultra Necro
I just came across this answer and read both it and John Dibling's objections below. It was apparent that I didn't explain what the above procedure does and why that does indeed remove main from the program entirely.
John asserts that "there is always a main" in the CRT. Those words are not strictly correct, but the spirit of the statement is. Main is not a function provided by the CRT, you must add it yourself. The call to that function is in the CRT provided entry point function.
The entry point of every C/C++ program is a function in a module named 'crt0'. I'm not sure if this is a convention or part of the language specification, but every C/C++ compiler I've come across (which is a lot) uses it. This function basically does three things:
Initialize the CRT
Call main
Tear down
In the example above, the call is _tmain but that is some macro magic to allow for the various forms that 'main' can have, some of which are VS specific in this case.
What the above procedure does is it removes the module 'crt0' from the CRT and replaces it with a new one. This is why you can't use the Runtime DLL, there is already a function in that DLL with the same entry point name as the one we are adding (2). When you statically link, the CRT is a collection of .lib files, and the linker allows you to override .lib modules entirely. In this case a module with only one function.
Our new program contains the stock CRT, minus its CRT0 module, but with a CRT0 module of our own creation. In there we remove the call to main. So there is no main anywhere!
(2) You might think you could use the runtime DLL by renaming the entry point function in your crt0.c file, and changing the entry point in the linker settings. However, the compiler is unaware of the entry point change and the DLL contains an external reference to a 'main' function which you're not providing, so it would not compile.
Generally speaking, an application needs an entry point, and main is that entry point. The fact that initialization of globals might happen before main is pretty much irrelevant. If you're writing a console or GUI app you have to have a main for it to link, and it's only good practice to have that routine be responsible for the main execution of the app rather than use other features for bizarre unintended purposes.
Well, from the perspective of the C++ standard, yes, it's still required. But I suspect your question is of a different nature than that.
I think doing it the way you're thinking about would cause too many problems though.
For example, in many environments the return value from main is given as the status result from running the program as a whole. And that would be really hard to replicate from a constructor. Some bit of code could still call exit of course, but that seems like using a goto and would skip destruction of anything on the stack. You could try to fix things up by having a special exception you threw instead in order to generate an exit code other than 0.
But then you still run into the problem of the order of execution of global constructors not being defined. That means that in any particular constructor for a global object you won't be able to make any assumptions about whether or not any other global object yet exists.
You could try to solve the constructor order problem by just saying each constructor gets its own thread, and if you want to access any other global objects you have to wait on a condition variable until they say they're constructed. That's just asking for deadlocks though, and those deadlocks would be really hard to debug. You'd also have the issue of which thread exiting with the special 'return value from the program' exception would constitute the real return value of the program as a whole.
I think those two issues are killers if you want to get rid of main.
And I can't think of a language that doesn't have some basic equivalent to main. In Java, for example, there is an externally supplied class name who's main static function is called. In Python, there's the __main__ module. In perl there's the script you specify on the command line.
If you have more than one global object being constructed, there is no guarantee as to which constructor will run first.
If you are building static or dynamic library code then you don't need to define main yourself, but you will still wind up running in some program that has it.
If you are coding for windows, do not do this.
Running your app entirely from within the constructor of a global object may work just fine for quite awhile, but sooner or later you will make a call to the wrong function and end up with a program that terminates without warning.
Global object constructors run during the startup of the C runtime.
The C runtime startup code runs during the DLLMain of the C runtime DLL
During DLLMain, you are holding the DLL loader lock.
Tring to load another DLL while already holding the DLL loader lock results in a swift death for your process.
Compiling your entire app into a single executable won't save you - many Win32 calls have the potential to quietly load system DLLs.
There are implementations where global objects are not possible, or where non-trivial constructors are not possible for such objects (especially in the mobile and embedded realms).