Basically the indent style I'd like to obtain is the one described as 'Lisp style' on Wikipedia:
while (x == y) {
something();
somethingelse(); }
I'm using a custom .clang-format file (version 3.8) but I couldn't find any option suited for my need.
Thanks in advance.
The clang-format source code is pretty clean, it's not too difficult to read it or modify it once you get the idea.
Here's a patch I made like a year ago that adds a "break before brace after constructor initialization lists", in clang 3.7. (It didn't get merged after discussion unfortunately, but I kept using it for my own projects anyways.) It's not too much code: https://github.com/cbeck88/clang/commit/e4f65cf7ab3deea9e6c7cdd5900ad0362835e514
Figuring out how to build clang and run the clang unit tests is probably as much work as actually making a patch to do what you are saying.
As I recall, the source code is more based around adding breaks rather than removing them, so depending on exactly how you want to formalize your idea (is this only control structures? For if's? For brace ending a function or class?) it might be tricky. But I still expect you would be able to get it to work.
To my recollection, there are no built-in options to do something close to what you are saying.
Related
Now this works, but it's pretty ugly, and not too friendly when you need to do it a whole lot.
(gdb) break diff_match_patch<std::__1::basic_string<wchar_t, std::__1::cha
r_traits<wchar_t>, std::__1::allocator<wchar_t> >, diff_match_patch_traits
<wchar_t> >::diff_linesToCharsMunge
Breakpoint 4 at 0x100021a1c: file diff_match_patch.h, line 658.
(gdb)
I am able to set breakpoints from the line number. This is likely what I will resort to most of the time, because:
To set a breakpoint with the name of a function, if it happens to be underneath a pile of templates (such as a class inheriting STL containers... grumble grumble), you have to go through this ordeal to get the ungodly signature of it in order to break on a function.
Here's how I'm able to accomplish it, here on my OS X 10.8.4, you type break at the gdb prompt, then start going with the prefix (in this case it was diff_match_patch, the name of the class), then attempt to tab-complete. At this point I use tmux's search mode to isolate the signature of the function (diff_linesToCharsMunge) and you see what I have pasted there is the beginning portion of the function's signature, which is enough to get gdb to happily set a breakpoint on it.
Now I'd like to make this somewhat better, but I'm not sure how. I'd like to keep things clean and robust by staying on the command line.
I reckon that if I wanted a nice (and friendly) GUI interface a good way to go would be to set this code up in an XCode project and go from there.
But what sort of options are there for me if I want to take more of a core UNIX style approach?
gdb is solid, for sure (and boy am I glad it seems to work seamlessly with my clang-compiled C++11 code), but it's lacking many niceties like what we get from e.g. ipython. ipython has full blown syntax highlighting! The clang compiler produces nicely colored and super friendly (cf. gcc at least) errors and warnings. With the sweet squigglies to show you the parts of offending expressions! gdb is just feeling long in the tooth by comparison.
So I'm just trying to make this work a little less ... painful. The areas to improve...
have tab completion search from the middle of the function signature so I can just tab after typing the reasonable human-known name of the function
actually #1 about sums it up, but any viable workarounds that do other things (line number is one of them, i guess... sigh) are welcome. You know, I'm hoping maybe clang project has some epic feature rich gdb front-end.
Oh right, I knew about this, but had forgotten it. Just stumbled across another answer that mentioned it:
http://lldb.llvm.org/lldb-gdb.html
I am embarking on setting up my VIM with better autocompletion, mainly for classes. In my google research I came across omnicppcomplete and clang. I can't seem to figure out the advantage/disadvantage of the two. Does anyone know?
Also, is one easier to install on third party systems than the other?
Any feedback will help. Thanks!
Clang really 'understands' c++. That means it can tell the difference between a local variable named foo and a member function named foo. If you want to complete thisObject.fo..., it will not give you the fooContainer completion, but only the Object::fooMethod.
Also, Clang can handle all C-type languages, which ctags cannot.
Omnicppcomlete is based on ctags, which is merely a textual index of your source tree. So it will be denser, will most of the time do what you want; sometimes it will be less accurate. Which isn't a real problem.
I have not yet installed the Clang completion though :( You probably have to build clang yourself, while ctags most likely comes with your distribution.
I have a couple of simple C++ homeworks and I know the students shared code. These are smart students and they know how to cheat moss. I'm looking for a tool that can rename variables based on their types (first variable of type int will be int1, first int array will be intptr1...), or does something similar that I cannot think of now. Do you know a quick way to do this?
edit: I'm required to use moss and report 90% match
Thanks
Yep, the tool you're looking for is called a compiler. :)
Seriously, if the programs submitted are exactly the same except for the identifier names, compiling then (without debugging info) should result in exactly the same output.
If you do this with debugging turned on, the compiler may leave meta-data in the executable that is different for each executable, hence the comment about ensuring it is off. This is also why this wont work for Java programs - that kind of info is present whether in debug mode or not (for the purposes of dynamic introspection).
EDIT: I see from the comments added to the question that you're observing some submissions that are different in more than just identifier names. If the programs are still structurally equivalent, this should still work.
EDIT: Given that the use of moss is a requirement, this probably isn't the way to go. I does seem though that moss has some support for comparing assembly - perhaps compiling to assembler and submitting that to moss is an option (depending on what compiler you're using).
You can download and try our C CloneDR duplicate code detector. It finds duplicated code even when the variable names have been changed. Multiple changes in the same chunk are treated as just one; if they rename the varaibles consistenly everywhere, you'll get back a report of "one clone" with the precise variable subsitution.
You can try Copy Paste Detector with ignoreIdentifiers turned on. You can at least use it for a first pass before going to the effort of normalizing names for moss. Or, since the source is available, maybe you can get it to spit out its internal normalization of the code.
Another way of doing this would be to compile the applications and compare their binaries, so your examination is not limited to variable/function name changing.
An HEX editor can help you with that. I just tried ExamDiff (not free $) and I was happy with the result.
What packages do you use to handle command line options, settings and config files?
I'm looking for something that reads user-defined options from the command line and/or from config files.
The options (settings) should be dividable into different groups, so that I can pass different (subsets of) options to different objects in my code.
I know of boost::program_options, but I can't quite get used to the API. Are there light-weight alternatives?
(BTW, do you ever use a global options object in your code that can be read from anywhere? Or would you consider that evil?)
At Google, we use gflags. It doesn't do configuration files, but for flags, it's a lot less painful than using getopt.
#include <gflags/gflags.h>
DEFINE_string(server, "foo", "What server to connect to");
int main(int argc, char* argv[]) {
google::ParseCommandLineFlags(&argc, &argv, true);
if (!server.empty()) {
Connect(server);
}
}
You put the DEFINE_foo at the top of the file that needs to know the value of the flag. If other files also need to know the value, you use DECLARE_foo in them. There's also pretty good support for testing, so unit tests can set different flags independently.
For command lines and C++, I've been a fan of TCLAP: Templatized Command Line Argument Parser.
http://sourceforge.net/projects/tclap/
Well, you're not going to like my answer. I use boost::program_options. The interface takes some getting used to, but once you have it down, it's amazing. Just make sure to do boatloads of unit testing, because if you get the syntax wrong you will get runtime errors.
And, yes, I store them in a singleton object (read-only). I don't think it's evil in that case. It's one of the few cases I can think of where a singleton is acceptable.
If Boost is overkill for you, GNU Gengetopt is probably, too, but IMHO, it's a fun tool to mess around with.
And, I try to stay away from global options objects, I prefer to have each class read its own config. Besides the whole "Globals are evil" philosophy, it tends to end up becoming an ever-growing mess to have all of your configuration in one place, and also it's harder to tell what configuration variables are being used where. If you keep the configuration closer to where it's being used, it's more obvious what each one is for, and easier to keep clean.
(As to what I use, personally, for everything recently it's been a proprietary command line parsing library that somebody else at my company wrote, but that doesn't help you much, unfortunately)
I've been using TCLAP for a year or two now, but randomly I stumbled across ezOptionParser. ezOptionParser doesn't suffer from "it shouldn't have to be this complex"-syndrome the same way that other option parsers do.
I'm pretty impressed so far and I'll likely be using it going forward, specifically because it supports config files. TCLAP is a more sophisticated library, but the simplicity and extra features from ezOptionParser is very compelling.
Other perks from its website include (as of 0.2.0):
Pretty printing of parsed inputs for debugging.
Auto usage message creation in three layouts (aligned, interleaved or staggered).
Single header file implementation.
Dependent only on STL.
Arbitrary short and long option names (dash '-' or plus '+' prefixes not required).
Arbitrary argument list delimiters.
Multiple flag instances allowed.
Validation of required options, number of expected arguments per flag, datatype ranges, user defined ranges, membership in lists and case for string lists.
Validation criteria definable by strings or constants.
Multiple file import with comments.
Exports to file, either set options or all options including defaults when available.
Option parse index for order dependent contexts.
GNU getopt is pretty nice. If you want a C++ feel, consider getoptpp which is a wrapper around the native getopt.
As far as configuration file is concerned, you should try to make it as stupid as possible so that parsing is easy. If you are bit considerate, you might want to use yaac&lex but that would be really a big bucks for small apps.
I also would like to suggest that you should support both config files and command line options in your application. Config files are better for those options which are to be changed less frequently. Command-line options are good when you want to pass the immediate changing arguments (typically when you are creating a app, which would be called by some other program.)
If you are working with Visual Studio 2005 on x86 and x64 Windows there is some good Command Line Parsing utilities in the SimpleLibPlus library. I have used it and found it very useful.
Not sure about command line argument parsing. I have not needed very rich capabilities in that area and have generally rolled my own to save adding more dependencies to my software. Depending upon what your needs are you may or may not want to try this route. The C++ programs I have written are generally not invoked from the command line.
On the other hand, for a config file you really can't beat an XML based format. It's readable, extensible, structured, etc... :) Plus there are lots of XML parsers out there. Despite the fact it is a C library, I tend to use libxml2 from xmlsoft.org.
Try Apache Ant. Its primary usage is Java projects, but there isn't anything Java about it, and its usable for almost anything.
Usage is fairly simple and you've got a lot of community support too. It's really good at doing things the way you're asking.
As for global options in code, I think they're quite necessary and useful. Don't misuse them, though.
In a nutshell, I'm searching for a working autocompletion feature for the Vim editor. I've argued before that Vim completely replaces an IDE under Linux and while that's certainly true, it lacks one important feature: autocompletion.
I know about Ctrl+N, Exuberant Ctags integration, Taglist, cppcomplete and OmniCppComplete. Alas, none of these fits my description of “working autocompletion:”
Ctrl+N works nicely (only) if you've forgotton how to spell class, or while. Oh well.
Ctags gives you the rudiments but has a lot of drawbacks.
Taglist is just a Ctags wrapper and as such, inherits most of its drawbacks (although it works well for listing declarations).
cppcomplete simply doesn't work as promised, and I can't figure out what I did wrong, or if it's “working” correctly and the limitations are by design.
OmniCppComplete seems to have the same problems as cppcomplete, i.e. auto-completion doesn't work properly. Additionally, the tags file once again needs to be updated manually.
I'm aware of the fact that not even modern, full-blown IDEs offer good C++ code completion. That's why I've accepted Vim's lack in this area until now. But I think a fundamental level of code completion isn't too much to ask, and is in fact required for productive usage. So I'm searching for something that can accomplish at least the following things.
Syntax awareness. cppcomplete promises (but doesn't deliver for me), correct, scope-aware auto-completion of the following:
variableName.abc
variableName->abc
typeName::abc
And really, anything else is completely useless.
Configurability. I need to specify (easily) where the source files are, and hence where the script gets its auto-completion information from. In fact, I've got a Makefile in my directory which specifies the required include paths. Eclipse can interpret the information found therein, why not a Vim script as well?
Up-to-dateness. As soon as I change something in my file, I want the auto-completion to reflect this. I do not want to manually trigger ctags (or something comparable). Also, changes should be incremental, i.e. when I've changed just one file it's completely unacceptable for ctags to re-parse the whole directory tree (which may be huge).
Did I forget anything? Feel free to update.
I'm comfortable with quite a lot of configuration and/or tinkering but I don't want to program a solution from scratch, and I'm not good at debugging Vim scripts.
A final note, I'd really like something similar for Java and C# but I guess that's too much to hope for: ctags only parses code files and both Java and C# have huge, precompiled frameworks that would need to be indexed. Unfortunately, developing .NET without an IDE is even more of a PITA than C++.
Try YouCompleteMe. It uses Clang through the libclang interface, offering semantic C/C++/Objective-C completion. It's much like clang_complete, but substantially faster and with fuzzy-matching.
In addition to the above, YCM also provides semantic completion for C#, Python, Go, TypeScript etc. It also provides non-semantic, identifier-based completion for languages for which it doesn't have semantic support.
There’s also clang_complete which uses the clang compiler to provide code completion for C++ projects. There’s another question with troubleshooting hints for this plugin.
The plugin seems to work fairly well as long as the project compiles, but is prohibitively slow for large projects (since it attempts a full compilation to generate the tags list).
as per requested, here is the comment I gave earlier:
have a look at this:
Vim integration to MonoDevelop
for .net stuff at least..
OmniCompletion
this link should help you if you want to use monodevelop on a MacOSX
Good luck and happy coding.
I've just found the project Eclim linked in another question. This looks quite promising, at least for Java integration.
I'm a bit late to the party but autocomplpop might be helpful.
is what you are looking for something like intellisense?
insevim seems to address the issue.
link to screenshots here
Did someone mention code_complete?
http://www.vim.org/scripts/script.php?script_id=1764
But you did not like ctags, so this is probably not what you are looking for...