Improvements to libogc library

[Rexhunter99]

Hey all, mucking around with libogc at the moment and have found that the entirely c-style setup can be a little bothersome at times, it works perfectly fine of course, but there are some things that could benefit from C++ if the user is using the language.

For instance:

Code: Select all

#ifdef __cplusplus
class GXColor
{
public:
	uint8_t r,g,b,a;

	GXColor() {r=0; g=0; b=0; a=0;}
	GXColor( u8 R, u8 G, u8 B, u8 A) : r(A), g(G), b(B), a(A) {}
};
#else
typedef struct _gx_color {
 	u8 r;			/*!< Red color component. */
 	u8 g;			/*!< Green color component. */
 	u8 b;			/*!< Blue alpha component. */
	u8 a;			/*!< Alpha component. If a function does not use the alpha value, it is safely ignored. */
} GXColor;
#endif

That way C++ can get the added benefit of being able to define a color with the class constructor for GXColor. This removes a line or two from your own source with only the little bit of overhead from C++ classes.

I'm sure I'll find others... feel free to use these yourselves, after all, anyone can make them on their own XD

Note that GXColor is located in gx.h

Have a nice day.

[vuurrobin]

First of all, I doubt this would add any overhead in the program. The constructor would be inlined and would (probably) be the same as when it would be done manually.

Second of all, I don't think that the small benefit would be worth the trouble of maintaining this kind of code. Remember that every function that uses this would also have to be modified. That can quickly lead to ugly and hard to maintain code.

I think the best and easiest way would be to just add a function that takes the 4 parameters and returns a GXColor. If it would be inlined it (probably) wouldn't add any overhead either.

Code: Select all

static inline
GXColor makeGXColor(u8 R, u8 G, u8 B, u8 A)
{
	GXColor result;
	result.r = R;
	result.g = G;
	result.b = B;
	result.a = A;
	return result;
}

Then you can just use GXColor bla = makeGXColor(1, 2, 3, 0);

[Rexhunter99]

Remember that every function that uses this would also have to be modified. That can quickly lead to ugly and hard to maintain code.

I put it into my own copy of gx.h and the test build went perfectly fine, all instances of GXColor passed through the make process with no errors or warnings and using the class constructor worked a breeze.

Begging your pardon, you were right. I just went and twiddled with it a little and realized that it wasn't passing the data on the way I thought it would at the time.
Lesson learned: Do not attempt to program anything while completing an overdue piece of course work.

Anyway, I personally find constructors more appealing for the handling of things like colors. They look so much cleaner than C-style Functions that do the same thing. But that's a personal preference.

[WinterMute]

Modifying libogc headers locally is a pretty good way to make sure nobody else will be able to build your code ... don't do it. Put wrappers in your own code if you must .

I'm quite reluctant to add C++ code to the base libraries because it inevitably ends up requiring C++ to build anything and we have a lot of users who stick with C. Libraries written in C++ also need recompiled when we update gcc, whether they change or not.