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.
Related
Instead of writing a code like
FindObjectOfType<GameManager>().gameOver()
I would like to type just
gm.gameOver()
Is there a way to do that in Unity?
Maybe using some kind of alias, or some kind of namespace or something else. I am after making my code clean, so using GameManger gm = FindObjectOfType() in every file that uses a the GameManager is not what I am looking for.
In general I have to discourage this question. This is very questionable and I would actually not recommend this kind of shortening aliases for types and especially not for a complete method call ... bad enough when it is done with variables and fields by a lot of people.
Always use proper variable and field names thus that by reading the code you already know what you are dealing with!
how about storing it in a variable (or class field) at the beginning or whenever needed (but as early as possible)
// You could also reference it already in the Inspector
// and skip the FindObjectOfType call entirely
[SerializeField] private _GameManager gm;
private void Awake()
{
if(!gm) gm = FindObjectOfType<_GameManager>();
}
and then later use
gm.gameOver();
where needed.
In general you should do this only once because FindObjectOfType is a very performance intense call.
This has to be done of course for each class wanting to use the _GameManager instance ...
However this would mostly be the preferred way to go.
Alternatively you could also (ab)use a Singleton pattern ... it is controversial and a lot of people hate it kind of ... but actually in the end FindObjectOfType on the design side does kind of the same thing and is even worse in performance ...
public class _GameManager : MonoBehaviour
{
// Backing field where the instance reference will actually be stored
private static _GameManager instance;
// A public read-only property for either returning the existing reference
// finding it in the scene
// or creating one if not existing at all
public static _GameManager Instance
{
get
{
// if the reference exists already simply return it
if(instance) return instance;
// otherwise find it in the scene
instance = FindObjectOfType<_GameManager>();
// if found return it now
if(instance) return instance;
// otherwise a lazy creation of the object if not existing in scene
instance = new GameObject("_GameManager").AddComponent<_GameManager>();
return instance;
}
}
private void Awake()
{
instance = this;
}
}
so you can at least reduce it to
_GameManager.Instance.gameOver();
the only alias you can create now would be using a using statement at the top of the file like e.g.
using gm = _GameManager;
then you can use
gm.Instance.gameOver();
it probably won't get much shorter then this.
But as said this is very questionable and doesn't bring any real benefit, it only makes your code worse to read/maintain! What if later in time you also have a GridManager and a GroupMaster? Then calling something gm is only confusing ;)
Btw you shouldn't start types with a _ .. rather call it e.g. MyGameManager or use a different namespace if you wanted to avoid name conflicts with an existing type
Edit: This question is not off-topic as it describes an issue in data file handling with Turbo C++.
First of all, Turbo C++ is because of my school. Don't comment telling me to stop using it, I'm forced.
Introduction: I'm trying to build a DFH library, so I made all these functions to write, read, insert, delete, modify, etc.
I used stings to make the functions work for any filename passed to them.
What I understand (self-learned) from the whole making a class and then passing it's object in the read_stream.read((char*)& Object_1, sizeof(Object_1)); form to read the file, that you wrote using the same object is that: the class works as sort of a template to print data onto the file.
Question: I want to use them with different objects of different classes, so the class whose object these DFH functions use for performing the desired task should be sort of like a template.
I was thinking on doing something with templates or abstract class and inheritance but I'm a beginner so I need someone to point me in the right direction!
To clear up: I want to use the same functions by just including this source file into other programs containing different classes.
Example Code
class Data {
int user_id;
public:
void enter() { //Input Function
cout<<"\nID: ";
cin>>user_id;
};
void write(char* file_1) { //File Write Function
clrscr();
Data Object_1;
char ch;
int records_read =0;
ofstream fout;
fout.open(file_1, ios::binary|ios::noreplace);
do {
records_read++;
Object_1.enter(records_read);
fout.write((char*)& Object_1, sizeof(Object_1));
cout<<"\nDo you want to continue? Y/N - ";
cin>>ch;
} while((ch=='y')||(ch=='Y'));
cout<<"\nWrite Successful!";
fout.close();
}
How do I make the function write() work with any other class, without having to explicitly change the statement Data Object_1; ?
I'm currently designing the classes for an application I'm writing for my coursework, and I have two classes that sound as if they should be a base-derived class pair, and do indeed share two member variables, and my problem is that they each have seven member variables and no operations.
The reason for the structure of these classes is that I am building a RSS reader and I intend to have these two classes hold data on the feeds. The first one will hold the data on the feed itself, for example the source url, the location of the rss.xml file on local storage, when the feed was last updated, etc. The second will hold information on the articles contained within the feed such as the publication date/time and an integer index based on the publication date that will be used to chronologically sort the articles.
class feed
{
string title;
string description;
string feed_url;
string local_location;
string channel;
bool feed_is_changed; // This is a flag that will be raised and lowered
// when the feeds are being refreshed
double last_updated; // The last update date/time will be converted to a
//standardised double value
}
class feed_item
{
string title;
string description;
double pub_time;
double pub_time_in_sec; // I'm separating the seconds so they can be used
// for a 'sub-index' when there are multiple feeds with the same pubtime
// (there are restrictions on the data types we are allowed to use
// (concocting work-arounds will aid in understanding, etc))
double pub_date;
int pub_year;
int order_in_list; // The index that will be calculated from pub_time,
// pub_date, etc
}
The above code is not complete, I'm currently only identifying variables and functions, and the private/public bits will come once they're finalised. As you can see from the above code, the only two variables that are being shared are title and description.
I'm not sure if it's worth making them an entity-base pair and just deactivating the five irrelevant variables, if it's more efficient to just make them completely separate classes, or if this is an entirely situational concern, and that it can be argued either way. My concerns are that the code may become difficult to both maintain and scale, but that there may be execution overhead inherent in one method or the other. Any thoughts and advice on this would be most appreciated.
A feed_item isn't a feed, so it fails the Liskov substitution principle and shouldn't be a subclass. I should check your ears — this pair of classes absolutely doesn't sound like they should be subclasses.
Occasionally (very, very occasionally) implementation inheritance is a good idea, but it's usually better done by extracting shared parts into a separate class and using it in both implementations. Here, it's absolutely a terrible idea — there's no great sharing of code, so the benefits are at best vague. Keep your code simple!
Just one derived class? Then almost certainly inheritance is the wrong design.
Inheritance is limiting, and those limits often don't appear until later making the decision even more expensive.
My rule of thumb is to avoid inheritance unless and until I can make a clear and compelling case to use it.
If you really wanted a base class:
struct NamedItem { // or maybe just "Item"
string title;
string description;
};
struct Feed : NamedItem {/*...*/};
struct FeedItem : NamedItem {/*...*/};
Or, usually preferred and a better fit in this case, use containment:
struct ItemInfo {
string title;
string description;
};
struct Feed {
ItemInfo info;
//...
};
struct FeedItem {
ItemInfo info;
//...
};
In particular, if you have no idea how you'll use a "NamedItem" without knowing the most derived type, it doesn't make sense to use inheritance.
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.
I saw multiple examples in MSDN that uses to declare the internal fields at the end of the class. What is the point?
I find this a little embarrassing, because each time Visual Studio adds a method it adds it to the end of the class, so there is need every time to move it...
class A
{
public A(){}
// Methods, Properties, etc ...
private string name;
}
class A
{
private string name;
public A(){}
// Methods, Properties, etc ...
}
In C++, it makes sense to put the public interface of the class at the top, so that any user of the class can open up your header file and quickly see what's available. By implication, protected and private members are put at the bottom.
In C# and Java, where interface and implementation are completely intertwined, people would probably not open your class's source code to see what's available. Instead they would rely on code completion or generated documentation. In that case, the ordering of the class members is irrelevant.
If it's obvious the variable has been declared, and the code is by way of an example, then arguably this gets you to the bit being demonstrated quicker - that's all I can think of.
Add-ins like ReSharper will allow you to standardise and automatically apply this layout at the touch of a key combination, by the way, if it is what you want.
Many programmers strive for self-documenting code that helps clients to understand it. In C++ class declaration, they would go from most important (i.e. what is probably most frequently inspected) to least important:
class Class {
public:
// First what interest all clients.
static Class FromFoobar(float foobar); // Named constructors in client code
// often document best
Class(); // "Unnamed" constructors.
/* public methods */
protected:
// This is only of interest to those who specialize
// your class.
private:
// Of interest to your class.
};
Building on that, if you use Qt, the following ordering might be interesting:
class SomeQtClass : public QObject {
public:
signals: // what clients can couple on
public slots: // what clients can couple to
protected:
protected slots:
};
Then the same down for protected and private slots. There is no specific reason why I prefer signals over slots; maybe because signals are always public, but I guess the ordering of them would depend on the situation, anyhow, I keep it consistent.
Another bit I like is to use the access-specifiers to visually seperate behaviour from data (following the importance ordering, behaviour first, data last, because behaviour is the top-interest for the class implementor):
class Class {
private:
void foobar() ;
private:
float frob_;
int glob_;
};
Keeping the last rule helps to prevent visual scattering of class components (we all know how some legacy classes look like over time, when variables and functions are mixed up, not?).
I don't think there is any valid reason for this. If you run Code Analysis on a class declared like this you'll get an error as private fields should be declared on top of classes (and below constants).