According to the documentation Semanticmerge supports C++ natively.
But when I run it on a set of files (from TortoiseHg), despite the fact that they have a .cpp extension, it thinks they are C#. This of course messes up the language parsing and completely negates the whole point of the tool!
I can't see any settings for file associations, or a manual override for the current merge.
Lunch the SemanticMergeTool.exe with -l=cpp switch
For a complete set of options run SemanticMergeTool.exe -?
Related
I am using Vim 8.0 with Python3 and myint/ClangComplete for C/C++ completions. SDL_<tab> suggests every function and type from SDL. Is there any way to limit suggestions to SDL_EventType types, functions returning SDL_Windows, etc.? BidiComplete seems like a good place to start, since SDL_<tab>EVENT would match SDL_WINDOWEVENT and SDL_FIRSTEVENT, but not SDL_FINGERDOWN, etc. Ideally I would like to be able to filter by any/all of the fields in the ClangComplete popup menu, since I might be interested in 'functions that take an SDL_Window* as an argument or return one'. The filtering/searching mechanism can just be regex over whole text of each line in the PUM.
The Vim completion engine YCM already implements support for this feature, and integrates well with clang. http://ycm-core.github.io/YouCompleteMe/#c-family-semantic-completion
As I mentioned in my comment, it appears as though you're asking for fuzzy completion, which is a feature that has already requested (see: github.com/Rip-Rip/clang_complete/issues/388). You may be able to use toobig's modification to get what you want.
Is there a tool that generates C/C++ source code from XML (or something similar) to create command line argument parsing functionality?
Now a longer explanation of the question:
I have up til now used gengetopt for command line argument parsing. It is a nice tool that generates C source code from its own configuration format (a text file). For instance the gengetopt configuration line
option "max-threads" m "max number of threads" int default="1" optional
among other things generates a variable
int max_threads_arg;
that I later can use.
But gengetopt doesn't provide me with this functionality:
A way to generate Unix man pages from the gengetopt configuration format
A way to generate DocBook or HTML documentation from the gengetopt configuration format
A way to reuse C/C++ source code and to reuse gengetopt configuration lines when I have multiple programs that share some common command line options
Of course gengetopt can provide me with a documentation text by running
command --help
but I am searching for marked up documentation (e.g. HTML, DocBook, Unix man pages).
Do you know if there is any C/C++ command line argument tool/library with a liberal open source license that would suite my needs?
I guess that such a tool would use XML to specify the command line arguments. That would make it easy to generate documentation in different formats (e.g. man pages). The XML file should only be needed at build time to generate the C/C++ source code.
I know it is possible to use some other command line argument parsing library to read a configuration file in XML at runtime but I am looking for a tool that generate C/C++ source code from XML (or something similar) at build time.
Update 1
I would like to do as much as possible of the computations at compile time and as less as possible at run time. So I would like to avoid libraries that give you a map of the command line options, like for instance boost::program_options::variables_map ( tutorial ).
I other words, I prefer args_info.iterations_arg to vm["iterations"].as<int>()
User tsug303 suggested the library TCLAP. It looks quite nice. It would fit my needs to divide the options into groups so that I could reuse code when multiple programs share some common options. Although it doesn't generate out the source code from a configuration file format in XML, I almost marked that answer as the accepted answer.
But none of the suggested libraries fullfilled all of my requirements so I started thinking about writing my own library. A sketch: A new tool that would take as input a custom XML format and that would generate both C++ code and an XML schema. Some other C++ code is generated from the XML schema with the tool CodeSynthesis XSD. The two chunks of C++ code are combined into a library. One extra benefit is that we get an XML Schema for the command line options and that we get a way to serialize all of them into a binary format (in CDR format generated from CodeSynthesis XSD). I will see if I get the time to write such a library. Better of course is to find a libraray that has already been implemented.
Today I read about user Nore's suggested alternative. It looks promising and I will be eager to try it out when the planned C++ code generation has been implemented. The suggestion from Nore looks to be the closest thing to what I have been looking for.
Maybe this TCLAP library would fit your needs ?
May I suggest you look at this project. It is something I am currently working on: A XSD Schema to describe command line arguments in XML. I made XSLT transformations to create bash and Python code, XUL frontend interface and HTML documentation.
Unfortunately, I do not generate C/C++ code yet (it is planed).
Edit: a first working version of the C parser is now available. Hope it helps
I will add yet another project called protoargs. It generates C++ argument parser code out of protobuf proto file, using cxxopts.
Unfortunately it does not satisfy all author needs. No documentation generated. no compile time computation. However someone may find it useful.
UPD: As mentioned in comments, I must specify that this is my own project
I was looking for a solution to store program settings or options or configuration in C++. These could be settings that are exposed in a GUI and need to be saved between runs of my code.
In my search I came across boost.PropertyTree which seemed to be a good choice. I know boost is well respected code so I'm comfortable using it and so I started developing using this. Then I come across boost.program_options which seems to allow you to do the same thing but also looks more specialized for the specific use-case of program settings.
Now I'm wondering which is the most appropriate for the job? (or is there a 3rd option that is better than both)
EDIT:
fyi this is for a plugin so it will not use command line options (as in, it's not even possible).
UPDATE
I ended up sticking with boost.PropertyTree. I needed to be able to save changed options back to the INI, and I didn't see a way of doing that with boost.program_options.
Use boost::program_options. It's exactly what it's for. In one library you get command line options, environment variables options and an INI-like configuration file parser. And they're all integrated together in the Right way, so when then the user specifies the same option in more than one of these sources the library knows the Right priority order to consider.
boost::property_tree on the other hand is a more generalized library. The library parses the text stream into a uniform data model. But You need to do the real parsing -- that of making sense of the blob of data for your needs. The library doesn't know when to expect a parameter when it sees a particular option string, or to disallow specific values or types of values for a particular option.
After some digging around I think boost.PropertyTree is still the best solution because it gives me the capability to save the options after changing them from within the program which is a requirement.
There is a non-Boost possibility too. Config4Cpp is a robust, simple-to-use and comprehensively documented configuration-file parser library that I wrote. It is available at www.config4star.org.
I suggest you read Chapter 3 (Preferences for a GUI Application) of the Practical Usage Guide manual to read an overview of how Config4Cpp can do what you want. Then open the Getting Started Guide manual, and skim-read Chapters 2 and 3, and Section 7.4 (you might prefer to read the PDF version of that manual). Doing that should give you sufficient details to help you decide if Config4Cpp suits your needs better or worse than Boost.
By the way, the indicated chapters and sections of documentation are short, so they shouldn't take long to read.
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?
When I'm developing in C#, I heavily use GhostDoc to speed up the process of commenting my code. I'm currently working on a C++ project and I haven't found an equivalent tool. I know about Doxygen, but from what I know it is used to create documentation outside the code, not comments in the code. Are there any good equivalent tools? I would prefer one that runs in VS, but I could handle one that works in any IDE.
(Before someone brings it up, I don't rely solely on GhostDoc to create comments. I just use it to create the starting point for my comments.)
I've written an add-in, Atomineer Pro Documentation, which is very similar to GhostDoc (it generates/updates documentation comments to save a lot of time and effort when documenting), but it parses the code directly for itself and thus is able to handle C, C++, C++/CLI, C#, Java and Visual Basic code, and doesn't require the surrounding code to be in a compiling state before it will work. It will also automatically add/update documentation for more tricky things such as exceptions thrown within the body of a method.
It runs under Visual Studio 11, 2010, 2008 and 2005, and supports Documentation-Xml, Doxygen, JavaDoc and Qt commenting formats, as well as the format/style of comment blocks and the auto-doc rules used being highly configurable. It has a number of other handy features such as aiding conversions of legacy doc-comments to the above formats, and word wrapping in doc-comments and normal block comments.
The above is just a summary of some key features - This comparison of features with other products serves as a more complete list of the many other features available.
Visual Assist helps by providing custom scripts executed while typing (or on other).
For example, you can have a script for comments like this :
/************************************************************************/
/* My comment : $end$ */
/************************************************************************/
That would be suggested (via a combo-box exactly like intellisense) when you start typing "/**" for example.
When you select this suggestion (via Enter/Space/Click - customizable), it will insert the script where your cursor is and just replace markers that are between '$' characters by special values (like the current file name for example).
Here the $end$ marker will make the cursor be at this position when the script is executed. This way, you continue typing smoothly. For example with the previous script set, typing exactly :
/** this is a test comment to show you one of the many features Visual Assit!
will simply give :
/************************************************************************/
/* My comment : this is a test comment to show you one of the many features Visual Assit! */
/************************************************************************/
It's really easy to customize and the behavior of the suggestion (read : intellisense++) system is customizable.
Visual Assist might do the job, though I'm not absolutely sure.