I'm running through the libgit2 sample code for getting the content of blobs, and I've hit a problem with the line:
git_buf filtered_content = GIT_BUF_INIT;
I get error C2065: 'GIT_BUF_INIT': undeclared identifier, which makes sense, because I can't find this defined in any of the included header files. As nobody seems to have asked this question before I get the strong feeling I'm missing something obvious. Any ideas on what I need to do to use GIT_BUF_INIT?
That's declared inside the library because it references an internal buffer. You should zero the structure as usual for C.
If the examples contain GIT_BUF_INIT they were probably extracted from the tests and we missed that it's not available outside.
Related
I am creating a C++/CLI wrapper for native C code that has it's own Object typedef and am receiving the C2872 'Object': ambiguous symbol error when linking. The compiler output is:
1>C:\src\OS_kernel.h(27): error C2872: 'Object': ambiguous symbol
1>C:\src\OS_types.h(261): note: could be 'ObjectStruct *Object'
1>C:\src\OS_kernel.h(27): note: or 'System::Object'
It may be worth mentioning that I am mocking this native C code for the purposes of the C++/CLI wrapper; not sure if that opens up a potential solution that would otherwise not be available if no source code was available. I'm guessing there is a way to specify which definition I want the code to use, but I don't know how to specify that. Is that possible? I want to specify it to use the ObjectStruct *Object.
It would be great if I didn't have to modify the mock code since it could potentially be hundreds or thousands of individual places.
As an aside, I am also receiving this error for other types the native library is using, such as Buffer and Boolean.
OK, since you're getting the error in OS_kernel.h, I'm guessing that's part of the C code you're wrapping.
Obviously, one possible solution is to treat the name Object as a reserved word, and edit your C code to not use it. One could argue that this is the most correct solution, but it may not be possible to do that.
Depending on how you're referencing the C code, it may be reasonable to compile it as C++, and stick it entirely within a namespace. That way, when the C code (now C++ code) uses Object it will see the typedef within its namespace, and you'll have the option to reference either namespace in your code.
The fact that you're getting this error from your library's header file indicates to me that you've got a using namespace System; directive, and that the #include of your library's header files comes after that using directive. Consider removing the using namespace System;, or at least moving it after the #include. This way, you won't get that error in the library's headers, you'll just have to deal with it in your code.
I'm trying to write some code that uses git_diff_perfdata from the Libgit2 library.
git_diff_perfdata s;
However, when compiling on my Mac I get the error:
use of undeclared identifier 'git_diff_perfdata'
My understanding is that Libgit2 is meant to be used exclusively through the inclusion of git2.h. Is that correct?
git_diff_perfdata is defined in sys/diff.h and used in status.h
Should I be including sys/diff.h directly. If so, why? Alternatively, what errors might I be making? Looking at the header code I'm unable to see how sys/diff.h is included through anything that is included by git2.h.
Additionally, from what I can tell git_diff_perfdata isn't meant to be an opaque data type (i.e. only the pointer is defined).
I'm using the code downloaded from:
https://github.com/libgit2/libgit2/archive/v0.26.0.zip
The headers in sys are part of the public API, but they're a bit lower level. You can think of them as internal implementation details that have been made public because they might be useful to application developers. If you want to use them, include them directly.
What is a "suitable guard" and what does it look like?
Linked this question because it refers to the same compiler message and the answer mentions a guard but not how to create one. Looked through the AspectJ docs but did not find and answer there.
This Lint warning is usually switched off in AJDT (AspectJ Development Tools) within Eclipse, but you can activate it as a warning or even error like this (I had to do it to actually see it at all when trying to reproduce your issue):
You can just ignore the Lint warning because basically it only says that there is no way for certain pointcuts to populate the thisJoinPoint object lazily during runtime because the pointcut has no dynamic component like if(), cflow() or similar, which is actually good news because it means that all your joinpoints can be determined statically during compile/weave time and are thus faster than dynamic pointcuts. On the other hand, the warning says that the tjp object always has to be created because for some reason it is also always needed during runtime and thus cannot be instantiated lazily.
I realize that doing this can lead to compile errors. But is an import always safe if no (new) compile errors or warnings arise? If I use an import statement (e.g. to remove duplicate protocol definition warning), could doing so, on it's own, ever change the run-time behavior? What checks (if any) are necessary to ensure invariability of operation after a new header import?
Yes, importing a header can lead to run-time issues.
For example, you may get a warning that a selector is unknown so the compiler is making assumptions about its signature. If you fix that warning by importing the relevant header, then that changes the code the compiler is emitting. Generally, it would change the code from broken to correct, but that nevertheless results in a run-time change.
If you use #import, then the header could define preprocessor macros that radically alter the subsequent code. For example, it could #define setNeedsDisplay setHidden or something.
The only way I can think of to verify that importing the header didn't alter the generated code is to examine the generated code and compare before and after. You can ask Xcode or clang to produce assembly from the compilation. You could also use otool -tV to disassemble the binaries (although that wouldn't show changes in, say, static data like strings).
I am not even sure how to start.
I am developing an iPhone application with the latest Xcode and sdk using core plot and the core async socket library. Everything was fine until a few hours ago, when Xcode dumped a ton of "interface duplication" errors for no apparent reason.
The two files that are emitting errors are the AsyncSocket.h and an API client that I wrote in order to get data out of the target server.
The errors are the following:
Nested Redefinition error on all enums in AsyncSocket.h and my API client.
Redeclaration of enum on all enumerations in AsyncSocket.h and my API client.
Duplicate interface declaration on the AsyncSocket.h and the API client's interface file.
The error occurred between two builds of the application. NOTHING was changed during that time which is why I can't even begin to think what is causing this.
The API client is a really simple thing, it just uses the async socket to send queries to the server and then return the parsed results in arrays. Nothing complicated, as I am not that into objective c yet.
I wish I could give some more useful information but that is all I have.
i believe your problem results from a simple mistake. In the header file you begin with:
#interface ClassName : SuperclassName
while in the .m file you do:
#interface ClassName ()
When you forget the brackets, the compiler complains.
I hope this helps. Best wishes with your app.
I had this problem and the response above put me on the right track.
I created a new enum record in a .h file I use for all my Constants.
But I forgot to add the semi-colon on the end. This simple little syntax error resulted in some weird and confusing errors appearing on files other than the one which contained the error.
No doubt you've resolved this by now but it might fix someone else's issues in the future.
I also experienced the "Duplicate interface definition" error message and traced it to my having put an "#include xxx.h" in a header (.h) file instead of in the .m file where I intended to put it.