I have a embedded controller code handed over, it has a bunch on .c files and some headers and a lot of associated files for the embedded processor, its a motorola MC9S12DT256 and it uses a not-so-good compiler - Cosmic. i used Visual studio(just a txt editor) for modifying the code and it changes the hex file being burned to the processor.
I got it earlier this week and spent most of my time on it and it worked ok for minor changes (where changin a value in the code and compiling again made the necessary changes) Now i have to make some major changes. The code calls certain functions which are not to be found any where in the all of the .hpp/.h/.cpp i got. there are no associated dlls as well. I tried to find some basic link and put it in a .sln and still most data is not recognized (as in i cant go to declaration of defn).
So my question is - how to get to the function definiton to where it is called when VS blanks out. Find all references also does no help
Thanks
PM
They may be compiler intrinsics (functions provided by the compiler rather then in a library). But it is not clear how you have determined that they do not exist in a static library or why you think you should be able to see a definition (as opposed to a declaration).
When using Visual Studio as an embedded project IDE, you should create the project as a "makefile project" (even if you don't actually have a makefile), and you need to add all the necessary header paths for your embedded code and the Cosmic compiler standard header folder as include files to the project - VS scans the header files for declarations for Intellisense code completion and browser navigation.
Related
I migrated c++ solution with multiple projects from VS2010 to VS2012.
Projects have reference of libraries with path set as System variables.
Application is getting compiled and run. But Intellisense reporting errors for all symbols and header in libraries. In External Dependencies node in solution explorer, it is not showing header files of 3rd Party libraries.
Headers file with hard coded and relative paths don't have this issue.
When right clicked on Header declaration to open header files, it shows all paths specified in project by striping environment variable values. e.g.
if include paths are "C:\QT\Includes;..\..\VISLIB\Inc;$(PROBAL_SHT_LIB)\V18.05\Inc", then it will show message "File 'XX.h" not found in ....... Build system path:
C:\QT\Includes;..\..\VISLIB\Inc;\V18.05\Inc.
and strips $(PROBAL_SHT_LIB).
Also noticed that if I set new system variable, then it is not shown in "Macros". or code is not getting compiled with VS2012. To make VS2012 recognize this variable. I need to restart PC.
This was working fine with VS2010.
You should know that the frontend/parser used by intellisense is not the same as that used by the actual compiler.
They are not always updated in sync and they often have different levels of feature completeness and different bugs. Thus it is not uncommon for intellisense to complain about perfectly valid code that the real compiler will handle just fine.
That is, of course, not great - but it is a fact and noone but Microsoft can do anything about it.
I probably misunderstand how the compilers work,but I have the following situation.I have a VC++ 2012 project.The project contains an API with hundreds of classes.Now, I create 'main' entry point file where I just use some std stuff.The main doesn't include even a single header from the API.Yet when I compile I see that pretty everything from the API is getting compiled into the executable?Why does it happen?Is it something I should configure in the project properties?
Source files that are part of the project are compiled also if "unused" through headers and references from your main routine.
If you don't want those compiled simply remove them from the project. The compiler might be able to optimize everything away but that doesn't mean they're not compiled if part of the project first.
I've done some research on this and haven't found anything so I'm posting here.
I'm trying to export a framework I created into a DLL, and I've done this. My problem is I would like to remove the .h attachment so people can't read it when I'm ready to publish.
I'm sure this is possible. I've gone into closed source programs and games and they have DLLs, and no headers. It's really as simple as that, I'm just not sure how.
Tech Info:
Windows 8.1
Visual Studio 2013 RC
In order to compile a new program against a DLL, it needs the header files. However, once this new program is compiled, it no longer needs the headers - the links have already been setup by the compiler. You should be able to distribute just the executable, as well as the binary DLL files it links against.
Have you tried simply removing the header files? I'm assuming Visual Studio creates them because, like I said, to write new code against an existing library, you need to know the function signatures, but you should be able to just remove them and still run the application.
It also might be worth noting that, generally speaking, distributing headers for a closed-source application isn't really a problem. All the header files contain is, "I have a function called f which takes parameters A, B and C," which isn't super sensitive information. Generally, with a closed source application, the information you want to keep a secret is how the functions are implemented, not what their signatures are.
I recently switched to Visual Studio 2010 and for Intellisense not to take half a minute to show up when using boost libraries, Microsoft's suggestion seems to use precompiled headers.
Except that I never used them before (except when forced to by Ugly ATL Wizards (TM)), so I searched around to figure out how they work.
Basically, the Big Centralized stdafx.h approach seems plain wrong. I never want to include (even cheaply) a whole bunch of header files in all my sources. Since I don't use windows libraries (I make C++/CLI higher level wrappers, then use .NET for talking to the outside world), I don't have "a whole truckload of non-changing enormous headers". Just boost and standard library headers scattered around.
There is an interesting approach to this problem, but I can't quite figure out how to make this work. It seems that each source file must be compiled twice (please correct me if I'm wrong): once with /Yc and once with /Yu. This adds burden on the developper which must manually tweak the build system.
I was hoping to find some "automatically generate one precompiled header for each source file" trick, or at least some "best practices", but most people seem happy with including the world into stdafx.h.
What are the options available to me to use precompiled headers on a per source file basis ? I don't really care about build times (as long as they don't skyrocket), I just want intellisense to work fast.
For starters, you are reading the article wrong. Every file is NOT compiled twice. The file stdafx.cpp gets compiled once with /Yc (c, for create) before anything else and then every other file in your project gets compiled once with /Yu (u, for use) and imports the result of the previously created saved state from stdafx.cpp.
Secondly, the article is 7 years old and is talking about VC++ 6, so you should start off distrusting it. But even assuming the information in it still applies to VC++ 2008 or 2010, it seems like bad advice. The approach it recommends using /pragma hdrstop is solution looking for a problem. If you have headers that contain things you don't want in every file, then they simply shouldn't go in your pre-compiled header.
Your problem basically seems to be that Intellisense is slow for Boost in VS2010? I don't have a direct solution for this problem, but could Visual Assist X be an option for you? I have used it in various versions of Visual Studio now and with great pleasure. Not a direct solution, but it might work for you.
Precompiled headers aren't too bad if you use them properly.
Don't use them as a replacement for proper and precise #includes, but as a way to speed things up. Achieve this by making the precompiled header do nothing in release builds, only speeding stuff up in debug.
You are wrong, each file is only compiled once. You have one .cpp file that is compiled with /Yc and the rest are compiled with /Yu. The file with /Yc, which is stdafx.cpp by default, contains one line, #include "myMainHeader.h" (changed the name from the default) All other .cpp files must start with #include "myMainHeader.h" When your /Yc file is compiled, the entire internal state of the compiler is saved. That file is loaded when each of your other files is compiled. That is why you must start with including the PCH, so that the /Yu option doesn't change the result of compilation, only the time. Xcode does not make this requirement and will use a PCH regardless of if your .cpp file starts with the right include directive. I have used libraries that relied on this and could not be built without PCH.
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.