I'm trying to untangle some code I didn't write. There are a lot of #if statements nested throughout this long file. I'd like a way to quickly identify all the #if statements that surround a given piece of code. Trying to search the Web for "#if" is hard since that either gets hashtags or ignores the punctuation, and "conditional preprocessor directives" didn't turn up anything other than a description of what they are.
Are there any commandline tools that already exist to find all the #ifs affecting a given line?
I'm using Visual Studio 2015 Pro. Are there any extensions that do that?
Not a proper answer but you can use sublime text editor.
In sublime you can select #ifby pressing ctrl + Done by one.
and if you want to find all press ctrl + f and type #if it will select all.
it want take too long to download it. you can download it from here. it is only about 8 mb in windows.
I'm writing a vim auto-command for cpp files where I want an abbreviation for #include lines.
The goal is for the abbreviation to expand to #include <▐> with the pipe being the location of the cursor after expansion.
Since naturally the abbreviation is to be followed by a space I'm trying to remove the input space from the register and move on.
However even after exiting insert mode and returning, or any trick I could think of: deleting next key, keying in bs etc, the space is being entered after whatever series of commands the iabbrev includes.
Therefore I'm looking for something that will remove the space from the register AND put me still in insert mode.
Thanks.
Add this to your .vimrc:
autocmd FileType cpp iab <buffer> #i #include <><Left><C-R>=Eatchar('\s')<CR>
func Eatchar(pat)
let c = nr2char(getchar(0))
return (c =~ a:pat) ? '' : c
endfunc
In lh-cpp, I have in a C ftplugin (the place where such definitions should be)
iab <buffer> #n <C-R>=lh#map#no_context("#n ",'\<esc\>0i#include')<CR>
:Brackets < > -open=function('lh#cpp#brackets#lt') -visual=0
With lh#map#no_context() that prevents the expansion of #n within string and comment contexts -- sometimes, we want to be able to type auto s = "#n";, and lh#cpp#brackets#lt that recognizes a few contexts in which I can expand my < into <> (includes, templates, castings, etc).
As you see I don't automatically append "" nor <> here as I want to be able to choose between #include <foo> and #include "foo"
Back to abbreviations that don't eat the space characters, the answer is in the help, see Menix's answer.
To simplify my task, I've defined a command that automatically applies such function (in lh-brackets this time):
command! -narg=+ Iabbr execute "iabbr " <q-args>."<C-R>=lh#map#eat_char('\\s')<CR>"
command! -narg=+ Inoreabbr
\ execute "inoreabbr " <q-args>."<C-R>=lh#map#eat_char('\\s')<CR>"
Thus, I would define your abbreviation this way
:Inoreabbr <silent> <buffer> #n< #include <><left>
:Inoreabbr <silent> <buffer> #n" #include ""<left>
Or even better to not see these abbreviations triggerred in string and comment contexts:
:Inoreab <buffer> <silent> #n< <C-R>=lh#map#no_context("#n< ",'\<esc\>0i#include <>\<left\>')<CR>
" and so on
As you can see from #LucHermitte's answer (and the similar attempt by #Meninx before), eating that character is a bit involved.
Instead, I would recommend you upgrade to a snippets plugin (if you don't use one already). Snippets are like the built-in :abbreviate on steroids, usually with parameter insertions, mirroring, and multiple stops inside them. One of the first, very famous (and still widely used) Vim plugins is snipMate (inspired by the TextMate editor); unfortunately, it's not maintained any more; though there is a fork. A modern alternative (that requires Python though) is UltiSnips. There are more, see this list on the Vim Tips Wiki.
Depending on the snippet plugin, the expansion may need to be explicitly triggered, others may already support insertion without the trailing space. Usually, you can configure a default for the included filename (that can be overwritten easily) - this functionality cannot be had via Vim abbreviations alone.
alternative
If you don't want full snippets functionality just for this, I would recommend to define the abbreviation based on triggering it with <Enter> instead of <Space>. This should fit well for this example (the next code / #include will be on a new line, anyway), and so you don't have to artificially remove anything.
Suppose I have the following .hpp file open in vim:
#pragma once
#include "a.hpp"
#include "b.hpp"
#include "c.hpp"
#include <boost/something.hpp>
// some code
Now, let's say I want to search for any occurrence of the term Token in any of the included files (possibly in the files they include as well). How can I do this easily?
I would like to skip over any files not locatable from my current vimpath, e.g. in this case I might not have boost in my path so I would want it to simply not search in boost/something.hpp.
You can use the include-search functionality available in vim. In particular, this is the command required to search for all occurrences of Token when you have the cursor over that word:
[I Display all lines that contain the keyword under the
cursor. Filenames and line numbers are displayed
for the found lines. The search starts at the
beginning of the file. {not in Vi}
To jump to the first occurrence you can use:
[<Tab>
Taken from Bram's presentation Seven habits of effective editing at time 26'08".
This last command is also described in Vim's help as following:
[ CTRL-I Jump to the first line that contains the keyword
under the cursor. The search starts at the beginning
of the file. Lines that look like a comment are
ignored (see 'comments' option). If a count is given,
the count'th matching line is jumped to, and comment
lines are not ignored. {not in Vi}
See :help include-search for several methods to automatically search included files in Vim. For simple token searches, [i is probably the easiest solution. If you need a full regular expression, or if you don't have the token somewhere to put your cursor over it, you can use the :isearch command.
I have a bunch of PHP coded websites that have been recently moved to a PHP 5.4 server and they're throwing deprecation warnings and errors.
Is there a way to mass find & replace function names with the proper ones? For example, I would like to be able to replace all instances of session_unregister('someVar') with unset($_SESSION['someVar'])...
Should i use regex or is there an other way?
For this particular example you could use sed like this:
echo "session_unregister('someVar')" | sed 's/session_unregister(/unset\($_SESSION[/;s/)/])/'
A bit more flexible would be to use the C preprocessor. Assume your php source file name is my.php. Add extension .h so it becomes my.php.h. At the beginning of the file, insert:
#define session_unregister(X) unset($_SESSION[X])
Assume the file contains lines like in your example: session_unregister('someVar')
Run the preprocessor like this:
cc -E my.php.h
Now you should instead see unset($_SESSION['someVar'])
(plus some extra garbage you don't want).
Note that this just answers your particular question, but I wouldn't recommend it without more detailed testing.
This is one of my most dreaded C/C++ compiler errors:
file.cpp(3124) : fatal error C1004: unexpected end-of-file found
file.cpp includes almost a hundred header files, which in turn include other header files. It's over 3000 lines. The code should be modularized and structured, the source files smaller. We should refactor it. As a programmer there's always a wish list for improving things.
But right now, the code is a mess and the deadline is around the corner. Somewhere among all these lines—quite possibly in one of the included header files, not in the source file itself—there's apparently an unmatched brace, unmatched #ifdef or similar.
The problem is that when something is missing, the compiler can't really tell me where it is missing. It just knows that when it reached end of the file it wasn't in the right parser state.
Can you offer some tools or other hints / methodologies to help me find the cause for the error?
If the #includes are all in one place in the source file, you could try putting a stray closing brace in between the #includes. If you get an 'unmatched closing brace' error when you compile, you know it all balances up to that point. It's a slow method, but it might help you pinpoint the problem.
One approach: if you have Notepad++, open all of the files (no problem opening 100 files), search for { and } (Search -> Find -> Find in All Open Documents), note the difference in count (should be 1). Randomly close 10 files and see if the difference in count is still 1, if so continue, else the problem is in one of those files. Repeat.
Handy tip:
For each header file, auto-generate a source file which includes it, then optionally contains an empty main method, and does nothing else. Compile all of these files as test cases, although there's no point running them.
Provided that each header includes its own dependencies (which is a big "provided"), this should give you a better idea which header is causing the problem.
This tip is adapted from Google's published C++ style guide, which says that each component's source files should include the interface header for that component before any other header. This has the same effect, of ensuring that there is at least one source file which will fail to compile, and implicate that header, if there's anything wrong with it.
Of course it won't catch unmatched braces in macros, so if you use much in the way of macros, you may have to resort to running the preprocessor over your source file, and examining the result by hand and IDE.
Another handy tip, which is too late now:
Check in more often (on a private branch to keep unfinished code out of everyone else's way). That way, when things get nasty you can diff against the last thing that compiled, and focus on the changed lines.
Hints:
make small changes and recompile after each small change
for unmatched braces, use an editor/IDE that supports brace match hilighting
if all else failds, Ye Olde method of commenting out blocks of code using a binary chop approach works for me
Very late to the party, but on linux you can use fgrep -o
-o, --only-matching
Print only the matched (non-empty) parts of a matching line,
with each such part on a separate output line.
So if you fgrep -o { then you'll get a list of all the opening braces in your file.
You can then pipe that to wc -l and that will give you the number of opening braces in your file.
With a bit of bash arithmetic, you can do the same with closing braces, and then print the difference.
In the below example I'm using git status -s to get the short-format output of all modified files from my git repo, and then I'm iterating over them to find which files may have mismatched braces
for i in $(git status -s | awk '{print $2}'); do
open=$(fgrep -o { $i | wc -l); # count number of opening braces
close=$(fgrep -o } $i | wc -l); # count number of closing braces
diff=$((open-close)); # find difference
echo "$diff : $i"; # print difference for filename
done
I think using some editor with brace highlighting will help. There should also be some tools around that do automatic indention on code.
EDIT: Does this vim script help? It seems to do #ifdef highlighting.
Can you create a script that actually does all the including, and then write the whole stuff to a temporary file? Or try the compiler for helping you with that? Then you can use the bracket highlighting features of various editors to find the problem and you'll probably be able to identify the file. (An extra help can be to have your script add a comment around every included file).
This might not be relevant to your problem, but I was getting an "Unexpected #else" error when framing some header files in an #if/#else/#endif block.
I found that if I set the problem modules to not use pre-compiled headers, the problem went away. Something to do with the "#pragma hdrstop" should not be within an #if/#endif.
Have a look at this question (Highlighting unmatched brackets in vim)
Pre-compile your code first, this will create a big chunk with the include files stuffed into the same file. Then you can use those brace-matching scripts.
I recently ran into this situation while refactoring some code and I'm not a fan of any of the answers above. The problem is that they neglect to incorporate a pretty basic assumption:
Any given file (most likely) will have matching braces and if/endif macros.
While it is true one can have a C++ source file that opens a bracket or an if block and includes another module that closes it, I have never seen this in practice. Something like the following:
foo.cpp
namespace Blah{
#include "bar.h"
bar.h:
}; /// namespace Blah
So with the assumption that any given file / module contains matching sets of braces and preprocessor directives, this problem is now trivial to solve. We just need a script to read the files / count the brackets & directives that it finds and report mismatches.
I've implemented one in Ruby here, feel free to take and adapt to your needs:
https://gist.github.com/movitto/6c6d187f7a350c2d71480834892552ab
I just spent an hour with a problem like this. It was very hard to spot, but in the end, I had typed a double # on one line:
##ifdef FEATURE_X
...
That broke the world.
Easy one to search for though.
The simplest and fastest solution is to comment file from the end by consistent blocks. If the error still exists, then you not yet comment the open brace.