references (costant or not) can be optimised away by compiler but it is not required to do so. Generally references in same scope and passed to inlined functions are optimised away entirely. For others you will need to look into resulting code to see if that particular instance was optimised away.
I am using references to make different names for a variable.
Like:
int u_i1;
...
int const& sheep_count = u_i1;
int const& cloud_count = u_i1;
int const& wind_speed = u_i1;
These are different meanings of the same variable.
Like if I would use some functionality of union.
Is my approach good at all?
Yes, it is passed to inlined functions only.
How can you be sure? There is no way to ensure inlining.
These are different meanings of the same variable.
Can you elaborate wht do you want to do?
They are actually different names for variable. So wind_speed == cloud_count will always eveluate to true.
Just create new variable instead of repurposing old ones. Limit scope of old ones if nessesary.
I need to create an std::vector of objects of different types. But vector works only with the same objects.
There are 2 known ways:
1) not make it vector of objects directly, but of smart pointers to objects.
But as a I understand, this may scatter my objects in memory, so that vector of pointers will work slower than vector of objects.
2) use 1 type of object, make it multi-function. It might have more variables, as it has wider functionality, and few conditions rather than virtual methods.
I must tell that there aren't much types of such object. Like 90% all objects are of 1 type (so only 1 condition passed), the rest are rare, and there are like 5-10 types of objects, not more (as these are already sub-types of some special type of objects that I use in my program).
These special conditions make me sure that (2) is better.
Now, if I do (2) and use common variables, I must do some kind of aliasing myself, to make my code understandable.
It doesn't work with reference anyway...
For example, I would like to initialize my members through reference, but constructor doesn't understand my intentions. I mean, it does init reference, but not a variable through reference.
For example, draw a circle, a square or a rectangle.
I would like to have them all in 1 array to pass through them quickly.
To not create much variables, I use common variables. The problem is how to name them! The code gets harder to read when I operate with untitled variables (like u_i4 - what is it?).
Yes, I have considered, but I don't need it to switch between different types. It looks abusive to use variant.
I have just checked..
If I do
union {
int name1;
int name2;
}
it makes no run-time difference compared to just 1
int name;
So I can use same type unions just to make different names.
Like
union {
int sheep_count;
int star_count;
int wind_speed;
}
And have no issues with bad naming anymore.
WEIRD but works.
Look, if I don't use common variables,
Sheep would have own 5 variables, Star - own 5 and Wind - own 5.
The object would have 15 variables in total.
?
I looked through all the internet and didn't find anything serious about that.
If this is considered a very bad style that no one is even talking about, I don't clearly get why.
Show example how this is going to work.
Why not call variable sheep_count if you will use it to count sheeps?
Or, you know, call it count.
THere is something really bad happens in your program architecture. I mean really bad. If you are resorting to uninos, that happens when you are working with low-level stuff or really mess up.
Why 15 variables? Do your object contain one sheep, one Star and one Wind? If so, then you would not be able to safely reduce number of variables.
Hard to tell you concrete as I haven't finished my code yet...
Let's take such example again.
We have 2 object types: Sheep and Star.
Sheep has:
int leg_count
int cost
int hit_points
int head_size
int movespeed
Star has:
int color
int twinkle_period
int x
int y
Instead of making 9 different variables I can use some unions like
union {
leg_count //sheep
color //star
}
union {
cost //sheep
twinkle_period //star
}
union {
hit_points //sheep
x //star
}
union {
head_size //sheep
y //star
}
int movespeed //sheep
It is easy to read and write like that.
To be more concrete,
I am doing graphic objects for my program. Most graphic objects (90+%) are sprites. Some others are just points, lines, fireworks(?), etc.
For example, line requires 2 additional integer values, as it has 2 points. These 2 can be combined with some 2 of sprite through unions.
But there can be, let's say, fireworks, that is very different from sprites (90%) and requires about as many variables as sprite. Unions would fit especially there.
It would be much easier to just use classes. One Sheep class and one Star class, each of which contains the listed variables and operates on them and uses them.
If you want to have a vector of ints, just use a vector of ints and then if you want, use an enum to determine which element to access. But you haven't really given any good reason for shoving everything into a single vector, or for putting things into arbitrary unions. If you want to group things together, group them into either containers or classes or just have them all separated and use each one. The reason nobody talks about unions being used like this, is because there is no reason to.
I need to draw sprites, circles, squares and fireworks according to certain order, so I must have a vector of either these objects or pointers to these objects to pass through all of them, rendering each of them. As I understand, pointers to objects are being passed significantly slower than objects themselves, as the pointers are located close to each other, but the objects themselves being allocated through new or kind of that aren't.
This is why I am trying to implement objects of different types in 1 class and use unions to save some memory.
You can make them all inherit from a drawable class, and then have a vector of pointers to the drawables. If you're that worried about performace you can store the objects which are pointed to on the stack.