I'm importing a TLB file into my project since I'm using a COM DLL. A TLB file is a binary file, which I need to compile my source code and so I was wondering if it's good programming practice to commit it to the repository.
Yes, it's ok to put binary files in a source repository. The rule sometimes called 'do not put binary files in a source repository' should better be called 'do not put temporary files or files that are a compilation result in a source repository'. Basically anything that can't be produced from other files and is relevant for the project itself (i.e. no editor preference files) can be put in a repository.
A type library is normally created by midl.exe from an interface definition language (IDL) source file. Or from a utility like Tlbexp.exe or Regasm.exe which can generate a type library from a .NET assembly. If you don't have the source for the type library then there's little else you can do but check-in the .tlb. Note that a type library is very commonly embedded as a resource in the COM server. So checking in the binaries is an option too.
Note that it is technically possible to reverse engineer the IDL from the type library with the Oleview.exe File + View Typelib command. Not so sure that's useful when you don't actually control the source.
Related
I think that it would be a good idea to have a track of the build file of a project. But, I've read that build files should not be public, since they can contain "sensible" information.
Is recommendable to have the build file in the same repository of the source code? Even if the repo is public? If it is not recommendable, would I have to have an independent repo for each project only for the build file?
Edit: the projects would be plugins for Moodle. And, I've never used build systems before, as I guess you have already deduced.
You didn't mention what kind of build system you're using. Nevertheless, having the build file along the project source has advantages:
The build file is versioned the same way the source code is
You don't have to keep track of which build file belongs to which project
You shouldn't have any sensible information within a build file - most systems allow you do have encrypted authentication information in a build file. In the worst case, you'll have to keep the information stored elsewhere.
I'm in need of some sage advice here. Long story short, I'm rebuilding a - for me - relatively complex app comprised of about 7000 lines of code. I ran into a number of issues when I created the first iteration of my application and it seems to me that test driven development might just be the ticket.
I was pleased to see that Visual Studio 2012 now natively supports TDD in C++, so I went ahead and read as much as I could. Unfortunately, Vs2012 is fairly new and I feel the documentation is somewhat lacking. But this is a little beside the point. I'm relying mainly on the following guide on the MSDN site:
http://msdn.microsoft.com/en-us/library/hh419385.aspx#objectRef
It fairly clearly states that if the code under testing is to be built as an .exe, then the way forward is creating a separate test project and linking the output object file. I'm guessing they mean the object files? Or maybe not?
I'm honestly a little confused as to how many .obj's I need to link. At first I thought I needed to link every single obj file which is fairly tedious.
If anyone has experience doing this and could perhaps also recommend which macros or similar short cuts to use in order to make this process as painless as possible, I'd be much obliged!
This will depend on how you have your solution structured. The way I like to structure my solutions is to have three projects.
A .lib project that has my source code in it.
An executable project, linked with the .lib. This calls into the .lib in the main() call
A test project (exe), linked with the .lib.
With this structure you can use the Add New Reference... button in the Common Properties section and the references will be sorted for you (except the header include path found in C++\General\Additional include directories).
If you do not want to restructure your projects you can tell the linker about each obj file (Linker\Input\Additional dependencies). This may be a significant number of .obj files if you have a lot of classes that you want to test. Unfortunately, you may have issues if you use pre-compiled headers.
I would suggest restructuring the projects if you can.
There's a nifty option when you use a project dependency, that lets you choose between linking the output file or having the IDE automatically select all the object files from the other project as dependencies.
(Don't worry about the .NET stuff in the screenshot, this was taken from an project where a C++/CLI DLL included a native static library project. Just do the same thing with a native test project including a native DLL or EXE project, choosing to link with the inputs.)
Unit Test Project for a Native Application (.exe) Project
Add the Unit Test Project to the Solution
Right Click on the Solution, Add, New Project. Under Visual C++, choose Native Unit Test Project.
Add the Application as a Reference to the Unit Test Project
Right click the unit test project, Properties, Common Properties, References: Add the .DLL project as a reference. This tells MSVC to rebuild the application if it has changed since the last unit test build, before rebuilding the unit test project.
Tell MSVC to Where to Find the Application's Library and Object Files
Right click the unit test project, Properties, Linker, General: Edit Additional Library Directories and add the path(s) to your applications object and library files.
Collect all the .obj and .lib Names
Run this batch file from the subdirectory or subdirectories where your Application's object and library files are located, concatenate the .txt files if there is more than one directory. For convenience you might want to add the .txt file to your project.
: *** CollectObjLibFilenames.bat ***
dir /B *.obj > ObjLibFilenames.txt
dir /B *.lib >> ObjLibFilenames.txt
Tell MSVC to Link the Application Object Files to the Unit Test Application
Right click the unit test project, Properties, Linker, Input: Edit Additional Dependencies and add the application object filenames and library (.obj and .lib) file names (copy and past the files from ObjLibFileNames.txt).
If your Application project uses precompiled headers, don't forget to include the precompiled header object file(s), usually
stdafx.obj, If you omit it, you will get a LNK2011 error.
Microsoft says "If you use precompiled headers, LINK requires that all of the object files created with precompiled headers must be linked in."
I thought there would be a name collision if I added the object file containing my application's entry point, main(int argc, char *argv), but my unit test projects link successfully with or without main.obj. I have not tried linking a file with other entry point flavors (WinMain, wWinMain, wmain). If you have a name collision with one of those, you could aways change the name of your entry point (which would be weird): Properties, Linker, Advanced, edit the Entry point, and rename the Application's entry point function correspondingly. The option is not specified in the unit test project I just looked at, which I assume means default, which almost surely is main(int argc, char *argv).
My main.cpp files have only one function (main) and no globals, i.e. no other part of the application refers to anything in main.cpp. I assume you can get away with omitting any object file if nothing in it is referenced by a linked file. Not worth the effort to figure out which satisfy that requirement for small applications. For large applications...good luck with that; Eventually you'll want to test all your execution paths anyway.
You will likely have a precompiled header object file, stdafx.obj file in the unit test project as well as the one in your application project. That will not be a problem, as the default object file names for the precompiled header files are $(TargetName).pch, where $(TargetName) resolves the project name. I.e., the pch object files will have different names.
Suggetion: Rather than copying the contents of my application's stdafx.h file into the corresponding unit test file, include the application's stdafx.h in the unit test project's stdafx.h file, so you don't have to update the unit test's version when the application's file changes. #include <stdafx.h> works, but I use the relative path between the two projects (if their relative paths are stable), or the full pathname of the application's source file if that's more stable, to be sure the right file is found. See difference-between-include-hpp-and-include-hpp for an unsettling explanation about how #include"header.h" and #include are interpreted. Spoiler: it's another implementation specific feature of C++.
_________________________________________________________________________
As an aside, precompiled header files are specified on a per source file (.cpp) basis. An individual .cpp file can use only one precompiled header file, but you can have more than one precompiled header file in the same project. See this:
I program in C++. When I see the folder in which .cpp file is saved I found some files like cpp, o and exe.
Are there any other files also related when the program is run, such as bak, tds? What is the difference between them and when are they made. I mean I am in the impression that cpp is formed when we save, object file when we compile. When are the bak and exe files are made? Or correct me.
Now, unless you created the file yourself it's most likely somehow related to your toolset.
*.cpp, *.h => Source files. These are the ones you'll edit to do your programming.
*.o, *.obj => Object-files. These are the translated version of the source files (the *.cpp files to be more precise) and are the raw material for the Linker.
*.exe => The executable. After the Linker is through with your object files it chains all of them together to create the actual executable which can be run by your OS.
*.bak => Typically a 'backup' file, which is often used if there's a risky operation going on, so it will be easy to restore damage.
*.tds => I know this one as Turbo Debugger-File. It is required by the IDE to allow stepping through the compiled code, keeping symbols etc.
.cpp files are for source code
.h files are for headers
there may be also other files with various extensions which contain resources, project definition,
build definitions, make-files - it depends on the development environment / compiler.
the .o files are binaries generated from the source code
the .exe file is windows executable - this is probably the single file, you want to run the program.
and this files are created during build from all libraries and .o files.
.bak files are only backup of some previous version of .cpp or .h files. The creation depends on the development environment.
bak tends to indicate backup files of some sort, probably made by an editor when you edit the files. I had no idea initially about tds files but a cursory web search turned up the fact that they are likely files produced for Borland Turbo Debugger (tds stands for Turbo Debugger Symbols).
You may want to consider upgrading to a compiler that's been updated sometime in the last fifteen years. There's rarely an excuse for using technology that dated when there are far better (and free) alternatives available.
Generally, you write the cpp files and the compiler compiles them. o files are usually files that have been compiled to objects and these are then combined into an exe executable file.
Note that this all depends on your environment of course. For example, UNIX compilers rarely produce exe files since that's a DOS/Windows-ism.
Recently I discovered a problem on the midas and I fixed it, the problem now is that I want to use MidasLib not the midas.dll and with the source code I'm only able to build the DLL.
The source is C++ and I have very few knowledge with it. I know the MidasLib.pas uses internally midas.obj, so I need to create it to statically link the midas to my application. How to do it on C++ Builder? (XE)
When you compile C++ code, the compiler creates an .OBJ file for each .CPP/.C file you have and saves them somewhere on your computer. What happens in most cases is that one would run a linker on all of those .OBJ files to join them into a single EXE or DLL, but in your case you don't need those results. Your C++ Builder is, like most programming IDEs, automatically doing both the compilation and linking.
If you just want the .OBJ, you need to find where in your project folder C++ Builder is placing its .OBJ files (called its "intermediate output", typically, as it is the intermediate step between compilation and linking). So you must have a source file called midas.cpp or midas.c that produces a corresponding output file called midas.obj.
I am new to SVN and I want to commit a code to SVN using TortoiseSVN. I have C++ headers and source of the code, but I don't know how to organize the folders in an efficient way before uploading the version to SVN. Any suggestions about how people usually do? Is there any difference between the structure of codes for different languages, for example C++ or java. Should I follow any specific rules?
Update
So after checking the answers I made things a bit clearer. An usual folder structure is the following for one proyect:
/trunk
/branches
/tags
But I also found a similar structure that I liked a lot, which is:
/trunk #Keep it to developement mode always.
/samples #samples of use
/modules #software modules
/project_modName
/include # .hpp files
/src # .cpp files
/test #unitary tests
/branches #experimental developements (copies of trunk at various stages)
/tags #estable versions
/extras
/3rdparty #libs
/data #necessary data for developement
/doc #documentation
/resources #for window applications
At least I like it for multimedia applications code.
UPDATE 2
This update is just to explain how I am creating my repository. I created a folder called structure_svn. Inside I created the structure showned above. I right click on the parent folder and select import. In URL I write the folder path (file:///c:/svn_repos) so automatically the structure is created under svn_repos, without the folder structure_svn.
I want to remark this beacause the folder you right-click on to import will never appear. I just realized when I tried it, and also is explained on toturials.
The next step is to successfuly divide my code inside the created structure.
Here's how I structure my tree in a programming project (mainly from a C/C++ perspective):
/
src — Source and header files written by myself
ext — External dependencies; contains third-party libraries
libname-1.2.8
include — Headers
lib — Compiled lib files
Donwload.txt — Contains link to download the version used
ide — I store project files in here
vc10 — I arrange project files by IDE
bin — Compiled binaries go here
obj — The compiler's build files
gcc — If your project size justifies it, make a separate folder for each compiler's files
doc — Documentation of any kind
README
INSTALL
COPYING
makefile — Something to automate generation of IDE project files. I prefer CMake.
A few notes:
If I'm writing a library (and I'm using C/C++) I'm going to organize my source files first in two folders called "src/include" and "src/source" and then by module. If it's an application, then I'm going to organize them just by module (headers and sources will go in the same folder).
Files and directories that I listed above in italics I won't add to the code repository.
Edit: Note that I'm using Mercurial, not SVN, so the structure above it tailored for that version control system. Anyway, I see from your update that you already found one that you like.
One huge step forward is making sure all your projects do out-of-source builds, ie put temporary file in $TEMP and put all output file in a dedicated bin/lib directory. If done properly, this leaves you with source directories containing only source. What's in a name.. Apart from 'pure' source files also make sure that everything needed to build the source is in the repository: project files/generators, resources.
Once you got that in place correctly, there's a good chance you only have to put some typical project generated files (like *.suo for Visual Studio) into SVN's ignore list, and you're ready for commit.
Basically you can put in svn just what you want. The only standard you might consider to follow here is the standard repository layout: See here:
Within the project you are right that there exists several best practices. And they are different for each language. E.g a Java Package is organized by namespace. In the C++ world I have seen two main ways how to organize it:
Every Class into a header (.h) and a source file (.cpp) inside the same directory
Header and source is separated (so you have an folder especially for headers) This is usefull for libraries so that this path can be used by upper layer projects.
Then you need a folder for third party libs, another one for the target files and others such as build files or documentation.
You have a good explanation in the next Link if you are noob with svn!!