c++, "combining" variables..
Hey say I have my class called "C", now this has a certain public variable.. However I would like to be able to access it by both typing "C.a = ..." and "C.b = ..."..
Is this possible in C++? (using typedefs?)
Make b a reference to a.
struct C{ C() : b(a) {} int a; int &b};int main(){ C c; c.a = 42; cout << c.a << ", " << c.b << "\n"; c.b = 43; cout << c.a << ", " << c.b << "\n";}
uhm aren't static variables just "global" over all objects of the class?
Now realize I did something wrong, I would like to:
And then c1.b should display also "10".. Also I would like to have it the opposite way around... (so b and a are interchangable). I know this could be possible using #define macro: but that changes everything for each file, yet I would only like to have this for this specific class!
EDIT: brother bob replied as I typed... I believe that's the way to do it :).
Now realize I did something wrong, I would like to:
Class C {};C c1;c1.a = 10;std::cout << std::c1.b;
And then c1.b should display also "10".. Also I would like to have it the opposite way around... (so b and a are interchangable). I know this could be possible using #define macro: but that changes everything for each file, yet I would only like to have this for this specific class!
EDIT: brother bob replied as I typed... I believe that's the way to do it :).
In the sake of instilling good programming practices early on, I'm more curious as to what you're trying to achieve by doing this? Why do you need A to be B, and B to be A? I think you're just going to confuse yourself more by programming this way.
Quote:Original post by paul23
uhm aren't static variables just "global" over all objects of the class?
Yes, with the difference that you can cherry pick (by using friend declarations) who will have access to those.
Use an unnamed union within a class like so:
I would generally discourage creating member aliases like that because it could be very confusing (imagine setting one variable while expecting its alias to remain unchanged).
#include <iostream>class C{public: C() : a(0) {} union { int a, b; };};int main(){ C c; c.a = 3; std::cout << c.b << std::endl; c.b = 5; std::cout << c.a << std::endl; }
I would generally discourage creating member aliases like that because it could be very confusing (imagine setting one variable while expecting its alias to remain unchanged).
Quote:Original post by Windryder
Use an unnamed union within a class like so:
*** Source Snippet Removed ***
I would generally discourage creating member aliases like that because it could be very confusing (imagine setting one variable while expecting its alias to remain unchanged).
Not sanctioned by the holy standard. The reference is the way to go.
But I agree on the discouragement: Don't do this but for transitional phases during some refactoring or so. Many compilers have options to declare certain names "obsolete" (e.g., in gcc:
struct X { int i; int &j __attribute__((deprecated)); X() : j(i) {}};int main () { X a; a.i = 3; a.j = 5; // gcc will warn you about j's deprecation}
)
Quote:Original post by phresnelQuote:Original post by Windryder
Use an unnamed union within a class like so:
*** Source Snippet Removed ***
I would generally discourage creating member aliases like that because it could be very confusing (imagine setting one variable while expecting its alias to remain unchanged).
Not sanctioned by the holy standard. The reference is the way to go.
But I agree on the discouragement: Don't do this but for transitional phases during some refactoring or so. Many compilers have options to declare certain names "obsolete" (e.g., in gcc:)struct X { int i; int &j __attribute__((deprecated)); X() : j(i) {}};int main () { X a; a.i = 3; a.j = 5; // gcc will warn you about j's deprecation}
Well my code used to work on "pairs": however since those pairs are actually x/y coordinates in a gird I thought: why using the "stupid" naming of pairs?
So instead of typedef I simply would like to make my own class.
Problem is: the code is already very much progressed (I'm now tidying up everything for if I would look back in a year or so).
And I want to keep everything working without too much work, so I thought this was the easiest way to go?
Then I'd say use references with compiler-specific deprecation warnings (if there is an important deadline or when you have team members), or go the hard way and edit all your code the compiler complains about upon recompiling (which I would prefer if I am the sole developer).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement