I was unable to find following vim completer feature. Say you write a code and you specify a type before including appropriate header file defining this type e.g.:
int main(){
uint8_t a = 0, b = 5;
...
return 0;
}
What you end up with is:
use of undeclared identifier 'uint8_t'
warning in VIM (I use YouCompleteMe) and a compilation error:
error: unknown type name ‘uint8_t’
What I'm looking for is a completer that suggests you something like
use of undeclared identifier 'uint8_t' did you include stdint.h?
If no such feature exists so far, what is the reason?
In lh-cpp I had a small feature, that given a ctags database will be able to add the inclusion statement related to the symbol under the cursor. Now I've extracted the feature to lh-dev.
I also remember to have defined an associative map that knows where a few symbols from the standard library come from, so far I only use it to automatically add the inclusion statement for types we inherit from in my C++ class snippets. What is sure, is that it could also be used for fixing missing includes (not everybody want to parse the standard library with ctags).
Note however, my scripts don't try to automatically detect all missing includes to add them. It's much too complex in real C++ projects.
You may need to add directory path to the -I option list of your compiler, or add the directory path to VIM's path option variable
:help 'path
If you don't know wich path to include, locate stdint.h could be a good start.
Related Link.
Related
I'm learning to use vim, but I think it's inconvenient to generate function definition in .cpp file from its declaration in .h file.
For example, if I declare a function void print(const vector<int>& arr); in A.h, I have to open A.cpp and type the following:
void print(const vector<int>& arr) {
}
(or use yy copy the declaration line, then delete ; and add {}...)
When some derived classes need to override function in base class, it can be a heavy job...
Is there any convenient plugin or command to help me deal with it?
My lh-cpp plugin has been providing this feature for quite some time now.
Go on the function declaration, type :GOTOIMPL et voilà!. It either moves the cursor to a function definition (from its declaration), or if none exists, it generates an empty shell to define that function.
Note: I'm currently in the process of improving the feature to support any kind of function declaration. To support template functions, you'd have to use the gotoimpl_with_libclang branch and the support plugin vim-clang (in V2Upgrade branch).
At this precise moment the sister command :MOVETOIMPL doesn't work as expected with constructors defined with initializer-lists, which has side effects on the :Constructor command. :MOVETOIMPL is meant to change an inline definition into a declaration plus a separate definition in a .cpp file typically.
Note: lh-cpp is a complex plugin that provides many things and that has many dependencies. Regarding overriding, it provides an :Override command to let us select which function we want to override -- this feature requires my current working branches of lh-cpp and vim-clang.
If you are using Neovim, you can try my plugin: cppassist.nvim, which can basically be used normally, but there are still many problems. Welcome to ask me questions!
This plugin will recursively search in your working directory until a file matching the same name with the counterpart extension is discovered. Note that the search also respects your .gitignore if one exists and any file ignored in git will be ignored in the results. As such, I suggest working from the root of your project. Once that file is found, it will automatically be opened in the current buffer. If no corresponding file is found, a message will be logged to the messages buffer -- use :messages to review your recent messages.
It uses regular expressions instead of LSP to generate function definition. Currently, it supports most keywords, as well as template types, and can generate multiple function definitions simultaneously in view mode.
However, the definition of nested classes is not currently supported. Also, if the function definition is already generated, press the shortcut key again and it will generate the function definition again.
I have downloaded libgcrypt library source code and I want to customize this standard shared library by adding my function inside one particular
source code file .
Although compilation/build process of customized shared library is successful, but it shows error at linking time.
Here is what I have done .
inside /src/visibility.c file, I have added my custom function,
void MyFunction(void)
{
printf("This is added just for testing purpose");
}
I have also include function prototype inside /src/gcrypt.h
void MyFunction(void);
#build process
./configure --prefix=/usr
sudo make install
nm command find this custom function.
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Here is my sample code to access my custom function.
//aes_gcrypt_example.c
#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>
int main()
{
MyFunction();
return 0;
}
gcc aes_gcrypt_example.c -o aes -lgcrypt
/tmp/ccA0qgAB.o: In function `main':
aes_gcrypt_example.c:(.text+0x3a2): undefined reference to `MyFunction'
collect2: error: ld returned 1 exit status
I also tried by making MyFunction as extern inside gcrypt.h, but in that case also I am getting same error.
Why is this happening ?
Is the customization of standard library is not allowed ?
If YES, then is there any FLAG to disable to allow customization ?
If NO, what mistake I am making ?
It would be great help if someone provide some useful link/solution for the above mentioned problem. I am using Ubuntu16.04 , gcc 4.9.
Lower-case t for the symbol type?
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Are you sure that's a visible function? On my Ubuntu 16.04 VM, the linkable functions defined in an object file have T (not t) as the symbol type. Is there a stray static kicking around and causing confusion? Check a couple of other functions defined in libgcrypt.so (and documented in gcrypt.h) and see whether they have a t or a T. They will have a T and not t. You'll need to work out why your function gets a t — it is not clear from the code you show.
The (Ubuntu) man page for nm includes:
The symbol type. At least the following types are used; others
are, as well, depending on the object file format. If lowercase,
the symbol is usually local; if uppercase, the symbol is global
(external).
The line you show says that MyFunction is not visible outside its source file, and the linker agrees because it is not finding it.
Your problem now is to check that the object file containing MyFunction has a symbol type T — if it doesn't the problem is in the source code.
Assuming that the object file shows symbol type T but the shared object shows symbol type t, you have to find what happens during the shared object creation phase to make the symbol invisible outside the shared object. This is probably because of a 'linker script' that controls which symbols are visible outside the library (or maybe just compilation options). You can search on Google with 'linker script' and various extra words ('tutorial', 'provide', 'example', etc) and come up with links to the relevant documentation.
You may need to research documentation for LibTool, or for the linker BinUtils. LibTool provides ways of manipulating shared libraries. In a compilation command line that you show in a comment, there is the option -fvisibility=hidden. I found (mostly by serendipitous accident) a GCC Wiki on visibility. See also visibility attribute and code generation options.
I'm trying to write a plugin for 3ds max, I went through the entire sdk installation process to the letter as described in the help files.
The problem I'm facing though is intellisence complaining about an invalid macro definition
"IntelliSense: command-line error: invalid macro definition:_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT =1"
I found the definition in project settigs -> c/c++ -> preprocessor definitions as inherited from parent or project default.
I tried disabling the inherited definitions and re-entered them, this time without the space between the name and the = and all works fine so I'm guessing its a typo on their part?
Anyway, I want to change the default project or whatever to not repeat it every time i start a new project. The project is created with a wizard which required me to copy over some files to appear and after which I had to enter the sdk path.
The files I copied are plain text with some fancy extensions and not much in them so I'm guessing the defaults are described in the sdk directory.. somewhere. Does anybody know what kind of a file I'm looking for?
EDIT: I found a file called root.vcxproj_template and it has a section for preprocessor definitions but all it contains is
<PreprocessorDefinitions>_USRDLL;%(PreprocessorDefinitions)</PreprocessorDefinitions>
and no mention of the broken one
EDIT2: in another part of the file there was a path to a property sheet (maxsdk\ProjectSettings\propertySheets\3dsmax.common.tools.settings) which included the faulty definition. I fixed it an no more complaints from VS.
_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_COUNT = 1 means that compiler should replace all old C run-time routines such as sprintf, strcpy, strtok with new versions such as strprintf_s, strcpy_s, strtok_s and similar. It goes in pair with following definition _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES = 1.
More you can find here: (MSDN) https://msdn.microsoft.com/en-us/library/ms175759.aspx. However I tried to use this but without success. It says that you can use this only for statically allocated buffers like char buffer[32], but compilers was still complaining bout unsecure strcpy.
What does this mean?
1>c:\users\vitali\documents\visual studio 2010\projects\salam\tools.cpp(107): error C2084: function 'bool readXMLInteger(xmlNodePtr,const char *,int &)' already has a body
1>c:\users\vitali\documents\visual studio 2010\projects\salam\tools.h(52) : see previous definition of 'readXMLInteger'
tools.cpp(107):
bool readXMLInteger(xmlNodePtr node, const char* tag, int32_t& value)
{
char* nodeValue = (char*)xmlGetProp(node, (xmlChar*)tag);
if(nodeValue)
{
value = atoi(nodeValue);
xmlFreeXOXL(nodeValue);
return true;
}
return false;
}
tools.h(52)
bool readXMLInteger(xmlNodePtr node, const char* tag, int& value);
Did you use include guards in your original header file?
For example:
#ifndef _TOOLS_H_
#define _TOOLS_H_
... your header body is here ...
#endif
This blocks against re-defining in each cpp where it is included.
It means that at some point your actual code is being re-read into the compile stream, so it seems two attempts at defining (as opposed to declaring) the function.
Suspect something about the way you set up the preprocessor statements.
Perhaps you already found the solution, but for me rebuilding the solution fixed it.
I moved my implementation from the header file to the .cpp file and the .pch file already had this info. So, I had to rebuild to fix this error.
The following doesn't actually answer your question, but I had the same problem with a different cause. This answer is only for the record.
Some people have a very bad style of adding code to the header file, resulting in constructor declarations like cMyClass() {} which is already considered to be a definition and not just a declaration (yes, even if it's located in the header file)
Removing those definitions by changing them into actual declarations e.g. cMyClass(); will solve this particular kind of problem.
It means the function is implemented somewhere else in your code.
Also, check if you have made a copy of the file (.cxx or .cpp extension) in the same directory. So the function will get defined twice.
I was getting the error for static functions!
Listen, this is going to sound dumb, but for anyone else coming across this, make sure you didn't accidentally try and include the cpp file instead of the header (right click file, copy full path, paste, it happens...)
Kept looking over that file extension for a while
You are getting this error because the header file is called multiple times from other locations. Insert #pragma onceat the top of your header file.
It is worth taking a look to your all references and find out duplicate calls. Or you have curly brockets (let say, empty ;)) in your header definition.
its true, i used the auto suggestion function on visual studio and it actually offered to include cpp file, i would have never thougt of..
I'm trying to use Valgrind on a program that I'm working on, but Valgrind generates a bunch of errors for one of the libraries that I'm using. I'd like to be able to tell it to suppress all errors which involve that library. The closest rule that I can come up with for the suppression file is
{
rule name
Memcheck:Cond
...
obj:/path/to/library/thelibrary.so
}
This doesn't entirely do the job, however. I have to create one of these for every suppression type that comes up (Cond, Value4, Param, etc), and it seems to still miss some errors which have the library in the stack trace.
Is there a way to give Valgrind a single suppression rule to make it completely ignore a particular library? And even if there is no way to make such a rule which covers all suppression types, is there at least a way to create a rule which ignores all errors of a particular suppression type from a particular library?
For most of the suppression types, you omit the wildcard, like so:
{
name
Memcheck:Cond
obj:/path/to/lib/lib.so.10.1
}
{
name
Memcheck:Free
obj:/path/to/lib/lib.so.10.1
}
{
name
Memcheck:Value8
obj:/path/to/lib/lib.so.10.1
}
Note that you must list each type of error separately, you can't wildcard them. You must also list the entire pathname of the library (as shown by valgrind, with any "decorations" like version numbers).
Also, leaks are handled differently -- for those you need something that looks like this:
{
name
Memcheck:Leak
fun:*alloc
...
obj:/path/to/lib/lib.so.10.1
...
}
It appears that it is necessary to include a separate suppression record for each type of error (Cond, Value4, Param, etc). But based on my testing with valgrind-3.6.0.SVN-Debian, I believe you can use the following simplified form for each type of error...
{
<insert_a_suppression_name_here>
Memcheck:Cond
...
obj:/path/to/library/thelibrary.so.*
...
}
{
<insert_a_suppression_name_here>
Memcheck:Leak
...
obj:/path/to/library/thelibrary.so.*
...
}
The three dots are called frame-level wildcards in the Valgrind docs. These match zero or more frames in the call stack. In other words, you use these when it doesn't matter who called into the library, or what functions the library subsequently calls.
Sometimes errors include "obj:" frames and sometimes they only use "fun:" frames. This is based, in general, on whether or not that function is included in the library's symbol table. If the goal is to exclude the entire library, it may work best if the library does not include symbols so that you can exclude based on the library filename instead of having to create separate suppressions for each function call within the library. Hopefully, Valgrind is clever enough to suppress errors based on library filename even when it does know the function name, but I haven't verified this.
If you do need to add suppressions based on individual functions within the library, you should be able to use the same form...
{
<insert_a_suppression_name_here>
Memcheck:Leak
...
fun:the_name_of_the_function
...
}
Note: You can include --gen-suppressions=all on the valgrind command-line in order to see the exact form and names (including any C++ mangling) required to suppress each error. You can use that output as a template for your suppression records -- in which you would usually want to replace most lines with ... in order to simplify the process of suppressing all errors that might occur in association with a specific library or function call.
Note: <insert_a_suppression_name_here> is a placeholder in which you can type whatever descriptive text that you want. It is required to not be blank.
nobar's answer almost worked for me, but I was getting a syntax error:
==15566== FATAL: in suppressions file "suppresion.error.txt" near line 4:
==15566== bad or missing extra suppression info
==15566== exiting now.
For system calls, I needed to add an extra line as the docs state:
Param errors have a mandatory extra information line at this point,
which is the name of the offending system call parameter.
So I ended up with this and it worked:
{
<sup_mmap_length>
Memcheck:Param
mmap(length)
...
fun:function_from_offending_lib
...
}