My project structure
MainProject (ARC)
SubProject(Non-ARC)
Boost library(i.e. Popular C++ library here is a link http://www.boost.org/)
Problem :
One of header file(intrusive_ptr.h) of Boost library has a inline function with "retain" statement(That file is edited by someone and it is working fine in "SubProject(Non-ARC)"). That header file is public, many files of subporjects are imported in "MainProject" and those file has a reference of this header file. So, indirectly that file comes in MainProject which is an ARC based. That's why compiler refuse to compile.
What I know or tried:
I know how to set the non ARC flag but that we can set only for .m file(compilable file only) not on .h file. if somebody could help me or suggest me any out of box solution.
For the persons who are interested in seeing the "intrusive_ptr.h" can find here intrusive_ptr.h. This file is a part of boost library so, suggestion should consider this library as well.
Any help or directions will be appreciated.
You can use the preprocessor to alter your header file using the technique from this answer
#if __has_feature(objc_arc)
//ARC-specific things
#else
//Non-ARC specific things
#endif
If you need Boost facility in some classes you can hide that using Objective-C++. Helper links:
http://philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects
http://support.apple.com/kb/TA45902?viewlocale=en_US
Related
I'm writing a library based on OpenVPN3, which is the C++ OpenVPN client implementation in header only, no cpp files. Therefore, I'm having to rely on having only one cpp file, which is the client itself, which includes a header that includes tons of other headers.
The problem is that, because of this, I cannot separate code into multiple cpp files. I'd like to be able for people to use my library, be it precompiled or compiled by them, but they cannot include the same headers on more than 1 cpp file or in the linking process there will be lots of redefinitions. There are also some static variables in the headers, for example.
If someone want to take a look at the number of things added into the 'master' header file: https://github.com/lucaszanella/libopenvpn3/blob/9b3440a736d90b671e9376d2d9e4911475e07112/src/OpenVPNClient.hpp
I know that there are some libraries like Asio that are also header-only and they're used without any problems by everyone.
Some techniques for not redefining a class or a function are to forward declare them but give no definition, but the problem here is that the person who's using my library is going to have to access its methods and everything. Is it possible to separate my methods from the ones used by my library on the headers?
you can put #pragma once on the most top of the file to avoid the same class clash due to being defined twice
If you do not want to duplicate import you can like tadman said:
at the top of the file
#ifndef HEADER
#define HEADER
//code goes here
#endif
I have a question about using C++ header files in Objective-C++ modules in Xcode. Specifically, why can I #include them in source files but not header files?
Here is a specific example.
I'm using Xcode 7.2.1 and have two projects. The first is a C++ framework I package into "myFramework.framework". It exposes "myFramework.h", which in turn pulls in "myLib.h". At the top of "myLib.h" is an "#include <string>".
The second project is an Objective-C iOS app which consumes the above framework. In this project, "myViewController.mm" (Objective-C++ source) has "#import "myFramework/myFramework.h" at the top and makes reference to things defined in that header file.
At this point all is well and good. It builds and runs with no issues.
When I move the "#import myFramework/myFramework.h" line to "myViewController.h", the compile fails because it cannot locate the "" header dependency.
It doesn't matter if I change the file type for "myViewController.h" to Objective-C++ header from plain old "C Header". Either way, Xcode's header search paths don't look for standard C++ headers.
So my main question is why does it behave this way? Why is a #include/#import treated differently just because it's in a header file?
My second question is if there's some way to make Xcode treat the #include/#import the same when it's in the header file instead of the source file?
Thanks much!
Are you sure that you get the error while compiling the myViewController.mm file?
Check if myViewController.h is imported into some other, non ObjC++ file (and that that one is the file that fails to compile).
I suspect the issue with including C++ headers inside other headers is that an Objective-C source file gets to see the C++ header file, which upsets it.
If you have mixed C++/Objective-C++/Objective-C then you are probably better off only exposing a pure Objective-C interface to other modules in the project and include any C++ header files in the Objective-C++ source files only.
Alternatively make everything Objective-C++ and then you don't need to worry about it at all.
Hopefully this answers your second question as well.
A header library is a library with all the code in the header.
If I have two cpp files that need code from the header lib, and if they both import the header, and both get compiled, the header file is getting compiled twice, I think. Would linking now throw and error because the header lib functions are being defined twice? If not an error, is this still bad practice?
What is the correct way to handle a header lib?
Just #include everywhere you want. If the library is not horribly broken, it will work fine. The library itself is responsible for having mechanisms that make it usable, in case of a header only library that means making it usable by including the header(s).
Nothing would make this bad practice, simply using by including is the purpose of a header only library.
Header files will use include guards (Include Guard wiki) that keep library functions from being defined twice. Basically, a header file will use a conditional statement that is evaluated during compilation that checks for an existing library definition. If it is defined already it ignores anymore additional definitions. These guards look like this:
/* library_name.h */
#ifndef SOME_IDENTIFIER
#define SOME_IDENTIFIER
[function prototypes]
#endif
A Daniel's Computer Blog article (Here) provides a very digestable explanation of what's going on behind the scenes and flushes out more nuances that I didn't address.
Baum mit Augen is right. If the lib uses include guards there will be no problem using #include<library_name> anywhere you want as many times as you want.
Ideally you will use #include<library_name> once at the top of any file that uses a function/class/constant from the library.
I'm in VS2013, C++ console applications. I'm having a problem integrating boost into a large framework. If I try integrating them in a blank console application, they work fine. Once I include the "root" .h file of the framework (that includes "many" other .h files in the bargain), it breaks. These .h files are "polluting" the boost ones (and anything included after, with mixed results, and no, I can't just include boost ones first, that's not always an option unfortunately). I've found at least one root-level #define that interfered and caused a compile error, but I can't find some of the other conflicts that are causing run-time problems.
Specifically, my problem is this: how do I tell what symbols have been defined by .h files? And hopefully, which ones are then conflicting later? I tried googling, but couldn't find a tool for doing this.
Or is there some other method which can "isolate" them (my problem .h files), and yet still have them link correctly to the functions they're calling in other .dlls?
You can use g++ -E as a static code checking tool (without changing your toolset). It is able to tell you when something is redefined but not when a #define is used as another name (it would have no way to tell whether it was a real substitution or not).
If that's not the source of your problem then you may need to take a more holistic approach: Start changing your project's #define use to other constructs such as const and short functions. This will then allow the compiler to either resolve differences by overloading or complain that there are conflicts.
Including same header file again might have caused the problem,you can create a symbol for each header file so that if that header file is already included in some other header file it shouldn't be included.
#ifndef
#define __header_file_name_H
.....some code
#endif
I am facing a problem regarding iostream file not found in header file.I just added a c++ file in my project a header file also included by default with some macro definition and including iostream file as
#ifndef __ObjectiveCPlus__File__
#define __ObjectiveCPlus__File__
#include <iostream>
#endif
but at this line I am getting error at include line as
I google it a lot and found various types of answer regarding this.But no one is able to correct my errors.
Please help
Thanks!
You don't need <iostream> in your header file, put it in your .cpp file. You're not referring to anything in the iostream library in your header file, using this library is more of an implementation detail.
Why?
I believe UIAppDelegate imports UIViewController.h, that includes MathUtils.h. Because UIAppDelegate's implementation is in a .m file, it's being compiled for Objective-C, and this chain of includes (which is all based on the header files) is including something that is C++. As such, the Objective-C portion is unable to find <iostream>, as that library does not exist in pure Obj-C.
Putting it in your .cpp file limits it to one compilation unit, the MathUtils unit. Having it in your header file includes it in all compilation units that have a dependancy on whatever is using it, which may not be Objective C++.
Alternative Solution
You could have your whole project as Objective C++ (in this case, by changing UIAppDelegate.m to UIAppDelegate.mm), which means C++ can be used throughout. I'm not a fan of this method, and it could mask bad coding practices.
I got the solution from another post:
Renaming your implementation file with .mm extension instead of .m will solve the issue.