Related
I start Microsoft Visual Studio 2010. I chose to start a new project on the Welcome Page. Ofcourse my preferred language is Visual C++ and I'm chosing to begin a Windows Forms Application. I give up a name like Calculator for this one. I do not touch the other options on this dialog. The project gets created and a new Form1.h is automatically added to the project, and a Form1.resX is also added. Because 'Form1' is useless to me, I'dd like to rename it to something more VB6 style, like "frmMain.h". So I right click the Form and simply chose "Rename". After accepting my new name, the necessary changes seem to be occuring. first impression But now, when I try to build this project, It gives a BUILD FAILED. When I look into my files.. Form1 is still mentioned..
So my question is: How do you actually/OFFICIALLY rename Forms?
I've been reading a lot about this and mostly the answer is to delete the form, and re add a new with the right name.. I've heard also that VS asks to rename all references to it, but that doesn't show up to me. Some other people say, you have to use the quick replace function, and rename all references to this class and its file.. This is not a good way to me.. Or is it really the standard procedure?
I have programming experience in C++ and I know about classes and polymorfism and so on. But this is one of the simplest things that keeps me annoying!
You are using VC++.NET to create .NET applications (Windows Form in your case). I must warn you that VS is not very friendly for VC (refactoring, renaming, and little intellisense).
In this case, you renamed the form which will make VS also rename the Form1.resX, but it will not rename the class. It will do it if in C# or VB.NET. Just open the .h file and rename the class itself to match the name of the file.
You also need to update the main .cpp file where "main" resides, and update the Application::Run(gcnew Form1()); in there as well include the "#include".
A solution replace will work (Ctrl+Shift+H), but be careful with this.
click on the form -> properties -> text (usually named as Form1) -> change it.
The property manager allows having different property sets for different configurations - for example, release and debug.
However, it still means you have to manually assign each property file to each configuration.
Is there some method to automatically assign a property set to a project based on some parameters (like configuration or platform)
a specific example:
I have a solution with many sub-projects.
this projects depend on various external libraries.
for each external library I have a .props file with the relevant directories and other parameters (include , lib, dll's...)
In some cases the directory names can be easily constructed using the default macros such as $(Configuration), $(Platform), etc.
However some libraries come with a less standard \ consistent naming convention.
for these cases I create .props file which are specific to a configuration (Debug\Release) - but it requires assigning the manfully to each project, which is tedious and error prone.
This is possible, at least in principle, see this post, for example. However, I did not find a practical way to use the whole power of MSBuild in combination with c++ projects from within the IDE. Whatever smart MSBuild expressions you write down in your property sheet, once you fire up the property manager dialog in the IDE everything gets overwritten with either defaults or the values inferred from there. This is an odd behaviour and completely different from other project types. Looks like they just wanted to keep the old pre-MSBuild style of editing VCProjects...
You can record a macro and use VBA to create/generate these with a button click.
in order to make new C++ classes conform to some rather picky coding conventions (upfront: I am not in the position to discuss these...), I was thinking about a way of generating stubs for new C++ classes. Currently, everyone is doing copy-paste, regularly missing some detail. The IDE in use is MS Visual Studio 2005, but I think there has not been much of a change in 2008 and 2010 regarding these topics.
My first idea was to implement a command line script to do this, which would be fairly straight forward to do. Alternatively, I thought about using a default VS extension mechanism for better IDE integration. So, this would be hooking in some custom stuff when selecting Add->New Item... on a filter (Solution Explorer).
After some investigation, I found out there is an easy-to-use templating mechanism, which unfortunately does not work for C++ (http://msdn.microsoft.com/en-us/library/6db0hwky%28v=vs.80%29.aspx). For C++, it seems like you have to implement a custom wizard instead, incorporating html for the layout and javascript for the logic.
Regarding the custom wizard approach, I've come to the conclusion that this would require some effort (at least for me) to get this done. MSDN is not very detailed on this topic. I've found some walkthroughs in the web, which are dealing with custom wizards for projects only (Add->New Project... instead of Add->New Item...).
So, here's the qn: Anyone having done this or something similar? Is it (better IDE integration) worth the effort (coping with the details of custom wizard implementation), or would you suggest the go for the command line tool instead? More than two days of work would not pay off in the current project, I guess.
If you think custom wizards are great, maybe you can give some hints to get started. Also, maybe there are alternatives I did not come up with. VS Add-Ins seemed to be over the top for this, and adapting e.g. VC\vcprojectitems\newc++file.cpp will not do the job.
Thanks in advance and best regards...
Jerb
I have done something similar using a custom wizard.
For my purposes I just wanted to inject some simple macros into each class to insert it into a static factory object.
I didn't need to modify the actual wizard, just copied the default generic class wizard and modified the code generation javascript.
The documentation is rubbish on the topic, but here is a good place to start for the javascript (that is where you are going to get the most power):
http://msdn.microsoft.com/en-us/library/t41260xs(v=VS.71).aspx
The default class wizard javascript is located here:
C:\Program Files\Microsoft Visual Studio
10.0\VC\VCWizards\CodeWiz\Generic\Class\Scripts\1033\default.js
Duping the Project
Duplicating this is trickier than I thought, you need to copy and paste the
Microsoft Visual Studio 10.0\VC\VCWizards\CodeWiz\Generic\
folder, then head to:
C:\Program Files\Microsoft Visual Studio 10.0\VC\VCAddClass\Generic
Dupe this folder and modify the Generic.vsdir inside it to point to a dupe of ..\Simple.vsz (a file in the VCAddClass folder).
The Simple.vsz file points back to the location of the "Generic" folder in VCWizards you duped at the start, so point your new simple.vsz at that.
Code Generation
As for the actual code generation, its not all that difficult to pick up. To get things started faster, here is the General way the default.js works:
Once the wizard is finished, the code gen method kicks off from:
function OnFinish(selProj, selObj)
selProj is (as far as I can tell) an instance of EnvDTE.Project
http://msdn.microsoft.com/en-us/library/envdte.project.aspx
Getting information from the wizard seems to be based around:
wizard.FindSymbol("CLASS_NAME")
The real magic starts to happen on the selProj.CodeModel object
oCM.AddClass(strClassName, strHeader, vsCMAddPositionEnd, "", "", vsCMAccessDefault);
It seems the convention for these methods to add anything to a file simply modifies the file as a single action, as it requires the file path as its paramter.
This returns a CodeClass instance and can be added to by its methods like:
AddAttribute
AddFunction
...
This is quite restricting if you are looking for very strict code formatting (or in my case inserting macros that don't fit normal code syntax.
The simple way around this is to just build a string on your own for the parts that you need full control over using the EditPoint interface.
An EditPoint is a location inside a code file to which you can call methods like:
EditPoint.Insert(string)
Editpoint.InsertFromFile(path)
To get an EditPoint in a location where you would want to insert code, simply use the location of one of the existing items in the code gen file (like class or constructor) and get a TextPoint using .StartPointOf or .EndPointOf and manipulating the parameters.
Once you have a TextPoint you can create an EditPoint like so:
newclass.EndPointOf(vsCMPartBody).CreateEditPoint().Insert("\nprivate:\n REGISTER_TYPE_MEMBER("+strClassName+");\n");
To get a TextPoint inside the .cpp file instead:
oConstructor.StartPointOf(vsCMPartWhole,vsCMWhereDefinition).CreateEditPoint().Insert("REGISTER_TYPE_BODY_ID("+strClassName+",REPLACE_ID);\n\n\n");
This gives you the power to do anything you want via JScript string manipulation as long as you can find the input data you need via the wizard (which I have not yet delved into)
I'm working on a static library project for a c++ course I'm taking. The teacher insists that we define only one function per source file, grouping files/functions belonging to the same class in subdirectories for each class. This results in a structure like:
MyClass
\MyClass.cc (constructor)
\functionForMyClass.cc
\anotherFunctionForMyClass.cc
OtherClass
\OtherClass.cc (constructor)
Whether this is good practice or not is something I'd not like to discuss, since I'm simply obliged to organize my project in this manner.
I'm working in visual studio 2008, and somehow got strange link errors when using an identically named function (and thus filename) in two classes. This appears to be caused by the fact that visual studio puts all .obj files (one for each source file) in one intermediate directory, overwriting earlier generated object files when compiling identically named source files.
This could be solved by putting the object files in subdirectories based on the relative path of the input file. Visual studio allows one to configure the names of object files it generates and has macros to use in there, but there appears to be no macro for 'relative path of input file'.
So, is there some way to get this to work? If not, is using one project for each class the best work-around?
You are right, by default all object files are put into the same directory and their filenames are based on the source file name. The only solution I can think of is to change conflicting file's output file path in here:
Project Properties-C/C++-Output Files-Object File Name http://img37.imageshack.us/img37/3695/outputfile.png
PS. It sounds like the lecturer has a crappy (probably written by the lecturer himself) automatic code verifier that imposes this restriction. To get extra marks, offer to rewrite the parser so it works with normal/sane/non-weird projet layout.
Real answer:
Change
C/C++ => Output Files => Output File Name
to
$(IntDir)/%(RelativeDir)/
Every .obj file is going to be created in a sub folder so its not going to overwrite the previous on linking.
I can't think of any way to fudge the project settings to get VStudio to automatically split out the intermediate files into separate folders.
You have a few chances -
Build the class name into each file name. Most IDE's display just the file name in the tab view so if you do have several methods in different classes with the same name, its going to be difficult to tell them apart if the file name does not include the class name along with the method name. Which is really why I think your teachers advice is madness. I have not seen any programming style guide advocating that approach. Additionally it goes directly against the way various tools work - if you use Visual Studio to create a class, it creates one cpp file and one header, and automatically appends each new function to the single cpp file.
You could create a static library per class. When linking in static libs the obj files are all packaged up inside the .lib so conflicts are no longer a problem.
Switch comp-sci courses to one thats not being taught by a nut job. Seriously, this guy is completely out of touch with industry best practices and is trying to impose their own weird ideas on their students: Ideas that are going to have to be unlearnt the moment they leave the teaching environment.
You can also change output file name per file in its properties. Just make sure you use different names.
Can you use the class name in the filename to disambiguate? I'm thinking that you might have
MyClass
\MyClass.cc (constructor)
\function1_MyClass.cc
\function2_MyClass.cc
That would mean that every file would have a unique-enough name to defeat the problem. Is that an acceptable strategy?
You could probably arrange the properties of the project to put the object files into a folder which is below the folder of each source file. Once the project has this property, then every source file should inherit this property. (But if you've done experiments like Igor has suggested, then you may need to go through the properties as reset them back to the parent).
Having looked at the help files, I think you should go to project properties/C C++/Outpuf Files/Object File Name: and enter $(InputDir) (no trailing backslash). Every source file should then inherit this property and your .obj files should be separated.
You may need to do a Clean Solution before you make any changes.
Renaming the object files will work, but it's going to be a pain, and it will slow your compile/link cycle down. I've never figured out why, but it seems to confuse Visual Studio if the object files don't have the default names.
You could prefix the funciton name with the class name; e.g. myclass-ctor.cc, myclass-function1.cc etc.
You could have one .cc file per class which #includes the individual function files. In this case you'll need to prevent the #included files from being compiled seperately (either rename their extension or set Properties->Exclude From Build to 'Yes').
Out of curiosity, where does your teacher want you to put free functions e.g. local helper functions that might normally belong in an anonymous namespace?
If not, is using one project for each class the best work-around?
Not a good idea - apart from the fact that you won't end up with a single static library (without even more jiggery pokery), your link times are likely to increase and it will hide a
lot of pertinent info from the optimizer.
On another note; If the course is actually about C++ not OO programming, do what you need to pass but take your teacher's advice with a pinch of salt.
You don't have to put them in different translation units... why not put each function in a .h and include them all in one .cc per class? That will very likely give better output from the compiler.
I'd be asking why the teacher is insisting on this odd structure, too, the reasoning behind it should be explained. I know you didn't ask that of us, so that's all I'll say.
In Visual Studio 2010, I set
Properties -> C/C++ -> Output Files -> Output File Name
to
V:\%(Directory)$(PlatformName)_$(ConfigurationName)_%(Filename).obj
for OBJ files to end up next to the sources assuming the project lies on drive V (no idea whether there is a macro for it, yet).
By the way: $(InputDir) refers to the solution/project directory and will cause the same problem in another directory.
I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.
This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.
So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.
Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.
Reason to create this plugin:
With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins.
Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name.
With plugin system inside the plugin there can be different project templates.
Above are some reasons why I will start the job. I'd like to hear your one.
There are multiple problems. Most of them are already solved by independent and generic plugins.
Regarding the definition of what is a project.
Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.
In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?
Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)
Regarding C++ code understanding
Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....
NB: That's where, now, I concentrate most of my efforts.
Regarding Doxygen
I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.
Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.
Regarding the debugger
There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.
Responses to other requirements:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())
work with source control system
There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.
debugger
source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
compile lib/project/one source file from ide
navigation by files in project
work with source control system
easy acces to file changes history
rename file/variable/method functions
easy access to c++ help
easy change project settings (Makefiles, jam, etc)
fast autocomplette for paths/variables/methods/parameters
smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
reformating selected block by convenstion
Things I'd like in an IDE that the ones I use don't provide:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
A "Tools" menu that is configurable on a per-project basis
Ability to rejig the keyboard mappings for every possible command.
Ability to produce lists of project configurations in text form
Intelligent floating (not docked) windows for debugger etc. that pop up only when I need them, stay on top and then disappear when no longer needed.
Built-in code metrics analysis so I get a list of the most complex functions in the project and can click on them to jump to the code
Built-in support for Doxygen or similar so I can click in a Doxygen document and go directly to code. Sjould also reverse navigate from code to Doxygen.
No doubt someone will now say Eclipse can do this or that, but it's too slow and bloated for me.
Adding to Neil's answer:
integration with gdb as in emacs. I know of clewn, but I don't like that I have to restart vim to restart the debugger. With clewn, vim is integrated into the debugger, but not the other way around.
Not sure if you are developing on Windows, but if you are I suggest you check out Viemu. It is a pretty good VIM extension for Visual Studio. I really like Visual Studio as an IDE (although I still think VC6 is hard to beat), so a Vim extension for VS was perfect for me. Features that I would prefer worked better in a Vim IDE are:
The Macro Recording is a bit error prone, especially with indentation. I find I can easily and often record macros in Vim while I am editing code (eg. taking an enum defn from a header and cranking out a corresponding switch statement), but found that Viemu is a bit flakey in that deptartment.
The VIM code completion picks up words in the current buffer where Viemu hooks into the VS code completion stuff. This means if I have just created a method name and I want to ctrl ] to auto complete, Vim will pick it up, but Viemu won't.
For me, it's just down to the necessities
nice integration with ctags, so you can do jump to definition
intelligent completion, that also give you the function prototype
easy way to switch between code and headers
interactive debugging with breaakpoints, but maybe
maybe folding
extra bonus points for refactoring tools like rename or extract method
I'd say stay away from defining projects - just treat the entire file branch as part of the "project" and let users have a settings file to override that default
99% of the difference in speed I see between IDE and vim users is code lookup and navigation. You need to be able to grep your source tree for a phrase (or intelligently look for the right symbol using ctags), show all the hits, and switch to that file in like two or three keystrokes.
All the other crap like repository navigation or interactive debugging is nice, but there are other ways to solve those problems. I'd say drop the interactive debugging even. Just focus on what makes IDEs good editors - have a "big picture" view of your project, instead of single file.
In fact, are there any plugins for vim that already achieve this?