I am aware of this script: http://www.vim.org/scripts/script.php?script_id=3797. It has been suggested a few times, and other questions regarding C++11 syntax for Vim have been shut down due to duplicating this question: Is there a C++11 syntax file for vim?.
Unfortunately, the suggested script results in scoping constructs (e.g. "namespace::member()") not being highlighted anymore, and functions and class names are no longer highlighted.
Does anyone have a better C++11 plugin for Vim available now? Ideally, all the features of the regular C++ plugin being retained, new keywords/reserved words marked (e.g. nullptr), lambda expressions/universal initialization syntax not flagged as errors. etc. etc.
Have you tried the following? I use this one and like it
http://www.vim.org/scripts/script.php?script_id=4617
Related
I'm trying to solve this bug report, where the documentation for a C++ library has some signature with ellipsis (... or ??) for places where the developers don't want to dive into the specifics (C++ metaprogramming is way too verbose); for example Tk_expr Ltuple<T1, ..., Tn>_expr::get<k>() const or Fmpz_expr::ternary operation(??, ??) const should just work.
If the documentation doesn't declare the language domain is C++, sphinx complains. If it does, sphinx complains it's invalid C++... I'm not sure if the information about Gentoo is important there.
Trivial fix : put complete signatures. Unreadable!
How can one use ellipsis?
Sphinx uses Pygments for syntax highlighting, and that's the source of the messages. You must have valid syntax for the language for highlighting to occur. You can either change the language to text which will remove desirable highlighting, or you can remove or comment out the elided output.
Coming from the Ruby world, I instantly understood why Crystal chose not to implement a for method. But then I was surprised to see that Crystal does implement a for method for macros. I was even more surprised to find that macros don't allow an enumerable (.each, etc) syntax (i.e. {% ["one", "two", "three"].each do |value| %} isn't valid macro syntax).
Is there a logical reason for this syntax difference? It's possible that the answer is simply ~"because the devs decided that macro syntax looks like x, and non-macro syntax looks like y", but I'm guessing that there is more to it then that (an arbitrary syntax inconsistency seems like a flaw).
Thanks!
The main reason is that when the parser parses foo.bar do |arg| ... end, it expects an expression after |arg|, not %}, which is a parse error. So to allow that we'd need to enhance the parser (which is already quite complex) to take that into account. for was decided because of this, but also to make it clear that it's just not regular crystal but a different thing (it's an interpreted subset of crystal and the standard library).
Another reason is that if each and other iteration methods are allowed, why not while and until? That could allow endless loops in macros, which with just for aren't possible, so you can guarantee a macro finishes executing. Which... is actually not true given that we have run inside macros.
So I think I'm not opposed to change the language to allow each, each_with_index, etc., inside macros, and allow that syntax, and eventually remove for from the macro language. Opening an issue requesting this is a good way in this direction.
I'm working on improving syntax highlighting for Ada in gtksourceview (currently, it is very outdated and very incomplete). An issue I'm having, is Ada is very positional, so matching many constructs requires matching those positions. I was able to do this in nano fairly easily.
So, let's consider a type declaration such as:
type Trit is range 0..2;
Keywords like "type", "is" and "range" are recognized (and were originally). However, type names were treated as keywords (a bad design decision, as Ada regularly defines new types, even for simple types like integers). What the use gets, is the types in Standard being colored, and all other types looking like normal text, defeating the purpose of highlighting. In some languages this might be a notable problem. However, the majority of type names occur after two regex patterns:
type\s+(\w|\.|_)+
:\s+(\w|\.|_)+
It might just be a matter of implementation (nano and gtksourceview seem to use different regex implementations). I thought the problem was recognizing spaces. As it turns out, putting the type context above the keyword context results in types now being highlighted, but the "type" keyword, or ":" operator are then not highlighted properly (they are highlighted as "type"). I was able to override this in nano, resulting in correct highlighting, but cannot seem to find out how gtksourceview does this.
Here you can see the old gtksourceview definition in action, which doesn't work for a file with many custom types. My nano definition in action sidebyside for comparison; matching by position is definately possible and works.
Here is what happens when I put the type context below the keyword context.
Here is what happens when I put the type context above the keyword context.
In both cases the context is the same, just a simple pattern to get started.
<context id="type" style-ref="type">
<match>(type)\s+\w+</match>
</context>
You may want to consider generating the parser from the formal description of the syntax of Ada in annex P of the Language Reference Manual.
Unfortunately this doesn't answer your question of how to formulate the syntax for a GtkSourceView.
I have seen the following definition throughout legacy code:
std::vector<boost::shared_ptr<ClassNameAAA>> vecClass;
I am able to compile it with VS2008 w/o problems.
Question> My understanding is that the following line should be used instead:
std::vector<boost::shared_ptr<ClassNameAAA> > vecClass;
^ Add a space here
Am i correct on this? If any, why VS2008 allows this?
Thank you
This is one of those several MS extensions.
Am i correct on this?
Yes your understanding is correct. >> would be parsed as right shift operator.
However C++11 supports right-angle brackets.
MSVC++ 2008 is able to parse this because of a language extension.
Many compilers have extensions for features that eventually become part of the language. Being able to parse nested template declarations without the space is now required in the new C++11 standard.
Does anyone know of a tool that I can use to find explicit C-style casts in code? I am refactoring some C++ code and want to replace C-style casts where ever possible.
An example C-style cast would be:
Foo foo = (Foo) bar;
In contrast examples of C++ style casts would be:
Foo foo = static_cast<Foo>(bar);
Foo foo = reinterpret_cast<Foo>(bar);
Foo foo = const_cast<Foo>(bar);
If you're using gcc/g++, just enable a warning for C-style casts:
g++ -Wold-style-cast ...
Searching for the regular expression \)\w gives surprisingly good results.
The fact that such casts are so hard to search for is one of the reasons new-style casts were introduced in the first place. And if your code is working, this seems like a rather pointless bit of refactoring - I'd simply change them to new-style casts whenever I modified the surrounding code.
Having said that, the fact that you have C-style casts at all in C++ code would indicate problems with the code which should be fixed - I wouldn't just do a global substitution, even if that were possible.
The Offload C++ compiler supports options to report as a compile time error all such casts, and to restrict the semantics of such casts to a safer equivalence with static_cast.
The relevant options are:
-cp_nocstylecasts
The compiler will issue an error on all C-style casts. C-style casts in C++ code can potentially be unsafe and lead to undesired or undefined behaviour (for example casting pointers to unrelated struct/class types). This option is useful for refactoring to find all those casts and replace them with safer C++ casts such as static_cast.
-cp_c2staticcasts
The compiler applies the more restricted semantics of C++ static_cast to C-style casts. Compiling code with this option switched on ensures that C-style casts are at least as safe as C++ static_casts
This option is useful if existing code has a large number of C-style casts and refactoring each cast into C++ casts would be too much effort.
A tool that can analyze C++ source code accurately and carry out automated custom changes (e.g., your cast replacement) is the DMS Software Reengineering Toolkit.
DMS has a full C++ parser, builds ASTs and symbol tables, and can thus navigate your code to reliably find C style casts. By using pattern-directed matches and rewrites, you can provide a set of rules that would convert all such C-style casts into your desired C++ equivalents.
DMS has been used to carry out massive automated C++ reengineering tasks for Boeing and General Dynamics, each involving thousands of files.
One issue with C-style casts is that, since they rely on parentheses which are way overloaded, they're not trivial to spot. Still, a regex such as (e.g. in Python syntax):
r'\(\s*\w+\s*\)'
is a start -- it matches a single identifier in parentheses with optional whitespace inside the parentheses. But of course that won't catch, e.g., (void*) casts -- to get trailing asterisks as well,
r'\(\s*\w+[\s*]*\)'
You could also start with an optional const to broaden the net still further, etc, etc.
Once you have a good RE, many tools (from grep to vim, from awk to sed, plus perl, python, ruby, etc) lets you apply it to identify all of its matches in your source.
If you use some kind of hungarian style notation (e.g. iInteger, pPointer etc.) then you can search for e.g. )p and ) p and so on.
It should be possible to find all those places in reasonable time even for a large code base.
I already answered once with a description of a tool that will find and change all the casts if you want it to.
If all you want to do is find such casts, there's another tool that will do this easily, and in fact is the extreme generalization of all the "regular expression" suggestions made here. That is the SD Source Code Search Engine. This tool enables one to search large code bases in terms of the language elements that make up each language. It provides a GUI allowing you enter queries, see individual hits, and show the file text at the hit point with one mouse click. One more click and you can be in your editor [for many editors] on a file. The tool will also record a list of hits in context so you can revisit them later.
In your case, the following search engine query is likely to get most of the casts:
'(' I ')' | '(' I ... '*' ')'
which means, find a sequence of tokens, first being (, second being any identifier, third being ')', or a similar sequence involving something that ends in '*'.
You don't specify any whitespace management, as the tool understands the language whitespace rules; it will even ignore a comment in the middle of a cast and still match the above.
[I'm the CTO at the company that supplies this.]
I used this regular expression in Visual Studio (2010) Find in files search box: :i\):i
Thanks to sth for the inspiration (his post)