View unanswered posts | View active topics It is currently Wed Jan 16, 2019 10:39 am



Reply to topic  [ 4 posts ] 
 Improvements to libogc library 
Author Message

Joined: Thu Sep 09, 2010 1:28 pm
Posts: 23
Location: Australia
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:
#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.

_________________
Move over Mario... and cruise by Crash... Croc Rocks!
It's a serious adventure 3D platformer for all retro gamers to drool over =D


Thu Oct 06, 2011 3:34 am
Profile WWW
User avatar

Joined: Fri Jul 11, 2008 8:49 pm
Posts: 222
Location: The Netherlands
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:
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);

_________________
my blog:
http://vuurrobin.100webcustomers.com/


Thu Oct 06, 2011 8:52 am
Profile WWW

Joined: Thu Sep 09, 2010 1:28 pm
Posts: 23
Location: Australia
Quote:
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.

_________________
Move over Mario... and cruise by Crash... Croc Rocks!
It's a serious adventure 3D platformer for all retro gamers to drool over =D


Thu Oct 06, 2011 10:04 am
Profile WWW
Site Admin

Joined: Tue Aug 09, 2005 3:21 am
Posts: 1314
Location: UK
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.

_________________
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog


Thu Oct 06, 2011 1:38 pm
Profile ICQ WWW
Display posts from previous:  Sort by  
Reply to topic   [ 4 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads