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.
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 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.
I have a maybe silly question. I coming from programming languages with exception handling, e.g. C++ and C#. At the time of Swift 1 I was confronted with the Cocoa Style with error objects (which somewhat reminded me at the ErrorObject in Microsoft COM).
After a time I began to use for my side project app an error handling pattern, in which I used a function parameter (closure) for error handling:
public typealias FailureBlock = (error:NSError!)->Void
JournalEntryStorage.instance.createJournalEntry(journalInfo, failure:
{
error in
NSLog("Watch App saveNewEntryInJournal: \(error.description)")
})
This solution seems nice at the time, because the function parameter forces me to code the error handling logic or I could simply make a call to a passed error handler function.
Now we have a solid error handling in place with Swift 2. Should I change my code completely to the new pattern? There is a lot of code.
How do you deal with your (legacy) code and the new error pattern?
By the way: I found the original Cocoa way with passing an error pointer and dealing with it so ugly in Swift 1. Maybe my method is more ugly but for me it seemed working.
I have decided for following solution and close the question:
a) I leave my old error handling pattern for all asynchronous function calls.
b) I am converting all synchronous functions to the new error handling scheme.
First impression. The code is much more readable.
Note: This is similar to this question but it is not the same. I promise.
I have a series of table views that call upon a modal view for sorting the table's contents. To do this, I set up a simple protocol in one table view controller's header file and it worked great. I then copied this protocol over to my other table view controllers and got this warning:
Duplicate protocol definition of 'ModalViewDelegate' is ignored
Now I realize it is just a warning, but I would rather not see it every time I compile. To get rid of the warnings, I imported the header file in which the protocol was originally defined. Once again, I was not completely satisfied. It seems sloppy to import the header file to every table view just so I can use the protocol without warnings.
If you have read this far, I thank you. My questions are 'Why is this happening? Is there a better way of getting rid of this warning while still using the same protocol?'
Is there a better way of getting rid of this warning while still using the same protocol?
The compiler needs to know about the protocol in order for you to refer to it. There's two ways you can make that happen: import the header where the protocol is declared into the files where you're using it, or make a forward declaration of the protocol in those files: #protocol MyProtocol;. The second is really only useful when protocols need to refer to each other (to avoid circular imports); if a class needs to adopt the protocol, it needs to see the declarations of the methods in the protocol, which means it needs to see the protocol declaration itself, i.e., the header.
It seems sloppy to import the header file to every table view just so I can use the protocol without warnings.
This is not sloppy, it's the way things work. It sounds like it may make sense for you to put the protocol declaration into its own header and import that wherever it's needed.
I discovered a similar warning where a #protocol was defined within the header of a class. Breaking that protocol out into its own .h and importing it elsewhere fixed it.
This is regarding creating the framework in iOS, as I have a bundle of unity which I want to create a framework, with data with-holding and linking library from Unity as libiPhone-lib.a. So without adding any library in the bundle target, the compilation works fine, if I include libiPhone-lib.a file, it generates a warning as:
warning: implicit declaration of function 'UnitySendMessage'
The UnitySendMessage is a function which is being called from the dedicated libiPhone-lib.a framework.
Any suggestions regarding this concern will be really appreciated.
Thanks.
This error means that, in the file where it occurred, UnitySendMessage was called without the compiler having seen a declaration for the function. You need to edit the file and #import the header that contains UnitySendMessage (or #include if it is a .c file)
.
The Unity folks seem to have neglected to include a header declaring this function. You can either declare it yourself, or just ignore the warning.