• Create Account

### #ActualServant of the Lord

Posted 29 December 2012 - 10:01 PM

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.

No, I want a new type with identical data and identical behavior, with the only change being no implicit conversion between the original type and the derivative.
It'd be a huge amount of unnecessary boilerplate code for virtually identical classes.

Here's a copy+paste of real code from my current project, using my macro version (which hides all the boilerplate, but has some flaws):
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)

Notice a common theme there? 13 of the 14 strong typedefs actually are identical classes. You'd have me manually create 13 different classes? No, I wouldn't bother. One or two, maybe. But since it's so easy with a good strong typedef, I can do a dozen with zero extra programming work, and gain the following benefits for free:
1) The code is more self-descriptive. cPoint is generic name, CellLoc tells much better what the variable is, so the variable name can tell its use. Example: "CellLoc centerCell;"
2) Compile-time bug catching of simple mistakes where data of one type (like inches, or tiles) is given when another measurement (like centimeters, or pixels) is expected. This is the primary motivation for me doing this, after several times (over the course of my current multi-year project) I got burned by subtle bugs that the compiler could've caught (and now does!) where I made a simple mistake that went uncaught for quite awhile. After implementing the system and recompiling, the compiler balked and gave a false positive... so I thought, until I looked closer and realized it caught a bug that I didn't yet know existed.

Again, it takes zero programming effort to get these benefits, if strong typedefs are available. Regular typedefs provide the first benefit only, and people only use regular typedefs in less than half the situations where they'd be beneficial, because the benefit they provide is so minor. Mostly people use typedefs for minimizing the typing work they have to do on long class names (which is a valid usage), instead of using the benefits of typedefs to increase code clarity.

My typedef'd items above may have gone a little overboard, and two or three of them probably don't make much sense (but do no harm either). The rest are very significant improvements to the readability and stability of my code.

### #1Servant of the Lord

Posted 29 December 2012 - 09:58 PM

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.

No, I want a new type with identical data and identical behavior, with the only change being no implicit conversion between the original type and the derivative.
It'd be a huge amount of unnecessary boilerplate code for virtually identical classes.

Here's a copy+paste of real code from my current project, using my macro version (which hides all the boilerplate, but has some flaws):
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)

Notice a common theme there? 13 of the 14 strong typedefs actually are identical classes. You'd have me manually create 13 different classes? No, I wouldn't bother. One or two, maybe. But since it's so easy with a good strong typedef, I can do a dozen with zero extra programming work, and gain the following benefits for free:
1) The code is more self-descriptive. cPoint is generic name, CellLoc tells much better what the variable is, so the variable name can tell its use. Example: "CellLoc centerCell;"
2) Compile-time bug catching of simple mistakes where data of one type (like inches, or tiles) is given when another measurement (like centimeters, or pixels) is expected. This is the primary motivation for me doing this, after several times (over the course of my current multi-year project) I got burned by subtle bugs that the compiler could've caught (and now does!) where I made a simple mistake that went uncaught for quite awhile. After implementing the system and recompiling, the compiler balked and gave a false positive... so I thought, until I looked closer and realized it caught a bug that I didn't yet know existed.

Again, it takes zero programming effort to get these benefits, if strong typedefs are available. Regular typedefs provide the first benefit only, and people only use regular typedefs in less than half the situations where they'd be beneficial, because the benefit they provide is so minor. Mostly people use typedefs for minimizing the typing work they have to do on long class names (which is a valid usage), instead of using the benefits of typedefs to increase code clarity.

PARTNERS