There's already a related discussion on std-proposals:
It may not be exactly what you're after but here is something interesting using the new c++11 user-defined-literal syntax.
http://www.codeproject.com/Articles/447922/Application-of-Cplusplus11-User-Defined-Literals-t
[quote name='Álvaro' timestamp='1356728174' post='5015178']
I have felt the need for something like this when I have classes Vector3D and Point3D, which are essentially the same thing, but I need to define them separately if I want the type system to help me make sure my operations make sense (e.g., you are not allowed to add points, but adding vectors is fine, and so is adding a point and a vector).
[/quote]
Ok, I got the idea. Still thats more like a copy of the type, rather than a typedef, so i suggest something like:
typecopy unsigned int Centimeters;
typecopy unsigned int Inches;
which should make an exact type copy under the specified name.
Also its not clear what to do with types hierarchy. Lets say:
class A {};
class B: public class A {};
typecopy B MyB; // should MyB also be a subclass of A or just copy the public part of an A interface?
I can see how this would be useful, but there was one (non technical) thing about the paper that didn't feel right.
"(The author of this proposal does not seriously endorse the use of macros for type aliases, and the
I don't want Centimeters and Inches to be convertible
Well and I don't understand why. As I wrote earlier built-in types with similar (in fact equal) semantics _are_ convertible.
You seriously don't understand why it's desirable to get a compiler error if someone has a quantity in centimeters and tries to use it where a quantity in inches is expected? I am not sure how else to explain it, since SOTL has been very clear.
How about this:
class Inch
{
float mValue;
};
class Centimeter
{
float mValue;
};
int main(void)
{
Inch i;
Centimeter c = i;
return 0;
}
test.cpp : error C2440: 'initializing' : cannot convert from 'Inch' to 'Centimeter'No constructor could take the source type, or constructor overload resolution was ambiguous
Am I missing something?
I can see how this would be useful, but there was one (non technical) thing about the paper that didn't feel right.
"(The author of this proposal does not seriously endorse the use of macros for type aliases, and the
above example was merely used for dramatic effect to trigger the gag reflex of any committee
members reading this)"
I'm not sure if papers like these are an appropriate place for smug jokes, but I would venture they're not.
How about this:class Inch { float mValue; }; class Centimeter { float mValue; }; int main(void) { Inch i; Centimeter c = i; return 0; }
Am I missing something?
myInch.mValue = 17;
myCentimeter.mValue = 35;
How about this:class Inch { float mValue; }; class Centimeter { float mValue; }; int main(void) { Inch i; Centimeter c = i; return 0; }
Am I missing something?
Yes, that makes the entire language very clunky. I would hate to have to do this:myInch.mValue = 17; myCentimeter.mValue = 35;
First, that code will not compile because mValue is a private member. Second, you can define the constructors and assignment operators so that you dont need to directly access mValue at all. Yes, there's some code you need to write for the class, but using it would be no different from using a built-in type, and you actually now have more flexibility in what operations you can do on your types and how to convert them, which get automatically converted and which result in compile errors, etc.
So I still dont understand why simply using a class is not an acceptable solution. You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.
So I still dont understand why simply using a class is not an acceptable solution. You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.
struct Vector3D {
double x, y, z;
Vector3D(double x, double y, double z) : x(x), y(y), z(z) {
}
void print(std::ostream &os) const {
os << '(' << x << ',' << y << ',' << z << ')';
}
};
struct Point3D {
double x, y, z;
Point3D(double x, double y, double z) : x(x), y(y), z(z) {
}
void print(std::ostream &os) const {
os << '(' << x << ',' << y << ',' << z << ')';
}
};
First, that code will not compile because mValue is a private member. Second, you can define the constructors and assignment operators so that you dont need to directly access mValue at all. Yes, there's some code you need to write for the class, but using it would be no different from using a built-in type, and you actually now have more flexibility in what operations you can do on your types and how to convert them, which get automatically converted and which result in compile errors, etc.
So I still dont understand why simply using a class is not an acceptable solution. You want a new type with your own defined data and behaviors... which is exactly what classes are meant for.
strong_typedef(cPoint, SubTileLoc, Point); //The position (in tiles, not in pixels) of a tile within a tileset image.
strong_typedef(cPoint, PosInImage, Point); //The pixel position in an image.
strong_typedef(cPoint, PosInMonitor, Point); //The position (in pixels) in the monitor itself.
strong_typedef(cPoint, PosInWindow, Point); //The position (in pixels) in the game window's client area.
strong_typedef(cPoint, PosInVirtualWindow, Point); //The position (in pixels) in the game's window, after accounting for the virtual window size.
strong_typedef(cPoint, PosInWorld, Point); //Position within the world, in pixels.
strong_typedef(cPoint, VisiblePosInWorld, Point); //Position within the loaded portion of the world, in pixels.
//strong_typedef(cPoint, PosInArea, Point); //Might be needed in the future (if I ever allow multiple _areas_ side by side).
strong_typedef(cPoint, PosInCell, Point); //Position within a cell, in pixels.
strong_typedef(cPoint, PosInTile, Point); //Position within a tile, in pixels.
strong_typedef(cPoint, TileLoc, Point); //The position of a tile within a cell, in tiles (not pixels).
strong_typedef(cPoint, CellLoc, Point); //The position of a cell within the area, in cells (not pixels).
strong_typedef(cPoint, VisibleCellLoc, Point); //The position of a cell within the loaded chunks, in cell (not pixels). VisibleCellLoc(0,0) is usually the cell the player is in.
strong_typedef(cPoint, TileOffset, Point); //The offset from the grid, in pixels, at which a tile is drawn. (0,0) is aligned with grid.
strong_typedef(cRect, AreaBounds, Rect); //Bounds of the area, in cells.
Ignore the third parameter, and read it as "typedef cRect AreaBounds;". (The 'c' in my classes are part of an abbreviated namespace, and do not stand for 'class'. Only a few basic times have that prefix)