When I compile my iPhone app, xCode gives "duplicate symbol" error for my variables in MyConstants.h
I thought if I used:
#import "MyConstants.h"
it would avoid that?
But I still have the problem.
Added info:
The error occurs during "linking".
(I'm just using xCode's "Build and Go" button.)
I also tried the (unnecessary with #import) #ifndef/def method, too.
Maybe I should just ask this:
If you needed to access a constant in EVERY part of ALL your source code files... what would you put in your .h file? What would you use to include that constant in other parts of your code.
I thought (but I guess it's not) it was simple as:
MyConstants.h> int thisIsGlobal = 123;
(No where am I re-defining thisIsGlobal anywhere in any code.)
And then just "#import MyConstants.h" at the top of each of my other source files.
What you can do is put in your header (MyConstants.h):
extern const int MyConstant;
extern NSString * const MyStringConstant;
And in a source file, include the header above but define the constants (MyConstants.m):
const int MyConstant = 123;
NSString * const MyStringConstant = #"SomeString";
Then, you simply need to include the header in any other source file that uses either of these constants. The header is simply declaring that these constants exist somewhere, so the compiler won't complain, because it's the linker's job to resolve these constant names. The source file that contains your constant definitions gets compiled, and the linker sees that this is where the constants are, and resolves all of the references found in the other source files.
The problem with declaring and defining a constant in a header (that is not declared as static) is that the compiler treats it as an independent global for each file that includes that header. When the linker tries to link all of your compiled sources together it encounters the global name as many times as you have included MyConstants.h.
Two options:
static const int thisIsGlobal = 123;
or
#define thisIsGlobal 123
I use like this, and works: (in a .h outside #interface)
static NSString * const mkLocaleIdentifierUS = #"en_US";
static NSString * const mkLocaleUserSystemSettings = nil;
This is because the symbol name in question (thisIsGlobal) is being emitted into every object file created, where the header containing the declaration for thisIsGlobal is included and visible.
The examples provided by another poster: 'extern const int MyConstant;' is the best way, unless you need the value to be visible, in which case you can use an enum:
int thisIsGlobal = 123; // bad
enum { thisIsGlobal = 123 }; // ok
using static will emit a lot of hidden symbols in a large program -- don't use it. Using a define is scary as well (considering there are safer alternatives available, why not use them?).
I usually put my application constants file in the Xcode project's MyApplication_Prefix.pch file, usually located within the Other Sources group. Any header file included in this pch file will be included from all files in your project.
After adding this include statement, you would then no longer need to include your MyConstants.h file from every file in your project — it will be included automatically.
Related
i'm coding an app with server API calls and I've got a private key for access, my question is: Where should I put that key? Let me explain a little more.
When we work for example in JavaScript we have a .env file, it contains sensitive content and is in most of cases on .gitignore file, so where is a correct place to save and access to those private keys on Xcode? or is correct simply to do something like:
let key = "MY_KEY"
thanks in advance
Even though what Codey said is correct but its much better to use a struct and create variables inside that struct. Simply making a variable 'key' might become troublesome in future as you might end up redeclaring it and losing everything. Also by using a struct, it gives much more clarity for the developer, it would make your code much more understandable.
Instead of going through that trouble do this.
Create a new swift file. Name is something like GlobalVariables.swift (or as Codey said).
Now create a struct inside that file.
struct serverInfo
{
static let key = "KEY"
static let server = "0.0.0.0"
}
You can access these variables anywhere on the program with
let x = serverInfo.key
let y = serverInfo.server
If this is only for development purposes, then you can store your password in the code. But note, that this file shouldn't be uploaded to your repository.
I would suggest to create a separate file (like Config.swift) and write your global configuration constants in this file.
// Config.swift
//
let key = "MY_KEY"
let server = "10.0.0.1"
You can then access these variables everywhere in your project. So this is the file you don't want to commit. Keep in mind, that everyone that uses your project needs such a file in order for the project to compile.
I have a whole bunch of constants that I want access to in different parts of my code, but that I want to have easy access to as a whole:
static const bool doX = true;
static const bool doY = false;
static const int maxNumX = 5;
etc.
So I created a file called "constants.h" and stuck them all in there and #included it in any file that needs to know a constant.
Problem is, this is terrible for compile times, since every time I change a constant, all files that constants.h reference have to be rebuilt. (Also, as I understand it, since they're static, I'm generating a copy of doX/doY/maxNumX in code every time I include constants.h in a new .cpp, leading to kilobytes of wasted space in the compiled EXE -- is there any way to see this?).
So, I want a solution. One that isn't "declare constants only in the files that use them", if possible.
Any suggestions?
The only alternative is to make your constants extern and define them in another .cpp file, but you'll lose potential for optimization, because the compiler won't know what value they have when compiling each .cpp`.
By the way, don't worry about the size increase: for integral types your constants are likely to be inlined directly in the generated machine code.
Finally, that static is not necessary, since by default const global variables are static in C++.
You declare them as extern in the header and define them in an implementation file.
That way, when you want to change their value, you modify the implementation file and no full re-compilation is necessary.
The problem in your variant isn't compilation-related, but logic related. They will not be globals since each translation unit will have its own copy of the variable.
EDIT:
The C++-ish way of doing it would actually wrapping them in a class:
//constants.h
class Constants
{
public:
static const bool doX;
static const bool doY;
static const int maxNumX;
}
//constants.cpp
const bool Constants::doX = true;
const bool Constants::doY = false;
const int Constants::maxNumX = 5;
I think your base assumption is off.
Your other headers are usually organized by keeping together what works together. For example, a class and its related methods or two classes heavily interlinked.
Why group all constants in a single header ? It does not make sense. It's about as bad an idea as a "global.h" header to include every single dependency easily.
In general, the constants are used in a particular context. For example, an enum used as a flag for a particular function:
class File {
public:
enum class Mode {
Read,
Write,
Append
};
File(std::string const& filename, Mode mode);
// ...
};
In this case, it is only natural that those constants live in the same header that the class they are bound to (and even within the class).
The other category of constants are those that just permeate the whole application. For example:
enum class Direction {
Up,
Down,
Right,
Left,
Forward,
Backward
};
... in a game where you want to express objects' move regarding the direction they are facing.
In this case, creating one header file for this specific set of constants is fine.
And if you really are worried about grouping those files together:
constants/
Direction.hpp
Sandwich.hpp
State.hpp
And you will neatly sidestep the issue of recompiling the whole application when you add a constant... though if you need to, do it, you're paying the cost only once, better than a wrong-sided design you'll have to live off with for the rest of your work.
What is the problem with this usage?
Do not declare a static type in header file, It does not do what you think it does.
When you declare a static in header file a copy of that variable gets created in each Translation Unit(TU) where you include that header file, SO each TU sees a different variable, this is opposite to your expectation of having a global.
Suggested Solution:
You should declare them as extern in a header file and define them in exactly one cpp file while include the header with extern in every cpp file where you want to access them.
Good Read:
How should i use extern?
Another approach which is best for compile times (but has some minor run-time cost) is to make the constants accessible via static methods in a class.
//constants.h
class Constants
{
public:
static bool doX();
static bool doY();
static int maxNumX();
};
//constants.cpp
bool Constants::doX() { return true; }
bool Constants::doY() { return false; }
int Constants::maxNumX() { return 42; }
The advantage of this approach is that you only recompile everything if you add/remove/change the declaration of a method in the header, while changing the value returned by any method requires only compiling constants.cpp (and linking, of course).
As with most things, this may or may not be the best is your particular case, but it is another option to consider.
The straight forward way is, to create non const symbols:
const bool doX = true;
const bool doY = false;
const int maxNumX = 5;
These values will be replaced by the compiler with the given values. Thats the most efficient way. This also of course leads to recompilation as soon as you modify or add values. But in most cases this should not raise practical problems.
Of course there are different solutions:
Using static consts, (or static const class members) the values can be modified without recompilation of all refered files - but thereby the values are held in a const data segment that will be called during runtime rather than being resolved at compile tine. If runtime perfomance is no issue (as it is for 90% of most typical code) thats OK.
The straight C++ way is using class enums rather than global const identifiers (as noted my Mathieu). This is more typesafe and besides this it works much as const: The symbols will be resolved at compile time.
I get a "unused static function" warning in Eclipse for code that looks like this:
my.c:
static void myfunc(void) { // This line gives unused warning.
printf("in myfunc()");
}
typedef void(* myfunctyp)(void);
#include "my_generated.h"
my_generated.h:
myfunctyp mylist[] = {
myfunc,
0
}
my_generated.h is a generated code so I cannot just put the array in the .c file.
My Questions are:
How can I tell Eclipse to look into the include file so it can accurately determine that the function is used?
If I cannot get #1, how can I add an indicator in the source code to tell eclipse that this particular warning is okay? I am aware that I can change Window->Preferences->Code Analysis -> Unused Static Function configuration to eliminate the error, but I would like something that "sticks" with the source.
[Edit (Addition)]: The function gets called in the main program like this:
mylist[0]();
If I move mylist[] declaration into the .c file, the warning error does not appear.
Here is one solution:
#define MARKASUSED(x) if (0) { x(); }
static void myfunc(void) {
printf("in myfunc()");
MARKASUSED(myfunc)
}
The 'if (0)' should cause the compiler to remove the code with any kind of optimization on so it would not impact runtime at all.
I don't think this solution is ideal, but it meets my immediate needs.
I added the Facebook sdk code to my project then I got this error because I already had a json library, so I deleted the Facebook json library from my computer and from the project but I still get this error. I search the whole project for "#interface SBJsonBase" and I only get one result. How can it say it's a duplicate when I only have one interface? Is it including the file twice? Does the search not always find everything?
May be this helps? Delete your derived data and do a clean project, then try to build again
I had a simular problem. It was a small search, but I could solve it without creating a new project etc...
The thing was I had a Class B that was importing Class A.
Then I had a class that imported Class B and also Class A.
When I did this, these problems occured.
Eg. A SOAP webservice Class imports all the Entities that are passed over the web.
Class goToSchoolWebservice.
import "person.h"
import "school.h"
...
Then I had a Singleton class used for caching that had the Logged in Person and also a ref to the webservice class.
import "person.h"
import "goToSchoolWebservice.h"
--> this is where is went wrong!!
So watch out for these circular references. ITs not so easy to detect them!
if your using #include instead of import then use this technique to minimize duplicates: at the begining of your interface (actually right before it) do check for a definition and if not defined then define it and proceed to define your interface. here is an example:
#ifndef __NetworkOptionsViewController__H // check if this has every been imported before
#define __NetworkOptionsViewController__H
#import "blahblah.h"
#interface NetworkOptionsViewController : UITableViewController
{
NSMutableArray* somevariable1;
int somevariable2;
}
#end
#endif
-- for me personally, i got this error though because the file path to my class was wrong. I checked file inspector and my class file was not defined in Classes folder even though the IDE said it was. I deleted them and copied them over again.
For those that still get this error, despite following header import conventions: I got this error from importing a header that had been deleted from the project. The missing header was instead found in an old backup of my project in dropbox (That I made before doing some destructive stuff in Git), and that file caused the circular import.
I solved a similar problem by moving all the imports to the prefix header file.
I'd like to know if it is possible to hide library implementation from consumers of a static library.
This great thread spawned a few questions in regards to a licensing system for static libraries: Licensing system for static library. The scheme I'd like to use is:
Give consumer a license key they put into a plist
plist is deployed
strong key is generated off of bundle identifier and matched against key in plist
Here is why that system is flawed: I need to run an algorithm (for strong key generation on the fly) that then outputs some string. The problem is I must include header files for the library to be used. At this point, anyone using the library can step into implementations. If I have a method named checkLicense(), a consumer of the library can step into that method and see how the strong key is being generated.
Also, for static methods, am I to run the key generation every time since there isn't any state? I could probably use a singleton and call it in each static method call?
My main problem is that implementation can be seen within a static library if you have the header files. Is there some way of hiding implementation?
Assuming this static library you are creating is written in Objective-C, one method you could use is to create an anonymous category of your class in your implementation file (not your header). In that category, declare your sensitive methods and then just implement them in your class like normal. This makes it so you don't have to expose those methods in your public headers.
For example, in SomeClass.m:
#interface SomeClass (/*Secret stuff*/)
- (BOOL)validateRegistration:(NSData *)key;
#end
#implementation SomeClass
// Other methods....
- (BOOL)validateRegistration:(NSData *)key { /* ... */ }
#end
Notice that this is an anonymous category because I haven't given the category a name (that's just a comment inside the parentheses). This makes it so you don't have to declare a separate implementation block specifically for that category's implementation, which helps hide those methods a little further.