operator SDL_Color 0.o?

[XianForce]

Well I've been reading through a copy of Focus on SDL that I bought from Amazon (Yay for used books?) and I was looking through the Framework stuff and saw that in the abstraction of SDL_Color. Unfortunately I don't have the CD (Down-Side of used books =/ ) and can't seek further understanding there.

From my perspective, when I see that operator keyword, my brain instantly thinks +, -, /, *, =, ==, +=, etc.

So first of all, what does operator SDL_Color() and operator SDL_Color*() mean, and how would I use them?

[RyanPridgeon]

It's not an operator, its a data structure. It contains a value for red, green, blue, and alpha(unused).

This is just a way to represent any colour, rather than having format dependent (such as indexed colour or 16 bit colour) colour data. That's why it's called abstraction.

Because it's a C struct, you can treat it as 32 bit colour data too. For example you could pass 0xFF00FF00 for a pink colour.

[XianForce]

It's not an operator, its a data structure. It contains a value for red, green, blue, and alpha(unused).

This is just a way to represent any colour, rather than having format dependent (such as indexed colour or 16 bit colour) colour data. That's why it's called abstraction.

Because it's a C struct, you can treat it as 32 bit colour data too. For example you could pass 0xFF00FF00 for a pink colour.

I know what an SDL_Color is... But in the Focus On SDL framework, it's stated like this:

operator SDL_Color()
and
operator SDL_Color*()

I want to know why a data structure is used as an overloaded operator, and how it would be used.

[programmerinprogress]

you can't make your own operators, you can only overload the pre-defined operators laid out by the language as far as I'm aware.

This sounds like a misprint, but I've never read the book.

[andrew]

They're conversion operators:

Code: Select all

//conversion operators
CColor::operator SDL_Color()
{
	//return color
	return(m_Color);
}

CColor::operator SDL_Color*()
{
	//return pointer to color
	return(&m_Color);
}

Check it out.

[XianForce]

They're conversion operators:

Code: Select all

//conversion operators
CColor::operator SDL_Color()
{
	//return color
	return(m_Color);
}

CColor::operator SDL_Color*()
{
	//return pointer to color
	return(&m_Color);
}

Check it out.

Thanks so much. I've been looking around my room for the disk, but I don't even remember if I ever had it. Couldn't find it on Google either, kept finding the ebook through a google search haha.

Well that's pretty nifty, you don't call the operators, it's just an automatic conversion =D.

EDIT: One more quick question.

Does this mean, I could just pass in a CColor object into any function asking for a SDL_Color, and it will do the necessary conversions? Or Would I have to do something like: CColorInstance->getColor()?

[Ginto8]

They're conversion operators:

Code: Select all

//conversion operators
CColor::operator SDL_Color()
{
	//return color
	return(m_Color);
}

CColor::operator SDL_Color*()
{
	//return pointer to color
	return(&m_Color);
}

Check it out.

Thanks so much. I've been looking around my room for the disk, but I don't even remember if I ever had it. Couldn't find it on Google either, kept finding the ebook through a google search haha.

Well that's pretty nifty, you don't call the operators, it's just an automatic conversion =D.

EDIT: One more quick question.

Does this mean, I could just pass in a CColor object into any function asking for a SDL_Color, and it will do the necessary conversions? Or Would I have to do something like: CColorInstance->getColor()?

almost. You could simply pass a CColor for a function asking for a SDL_Color, howerver, this will probably, if the compiler isn't too smart (or is smart, idk how these things work all the time), be a dynamic cast, which is slower (I think) and can have unexpected behavior (again, I'm not quite sure). The better thing would be to use a static cast, which can be done one of two ways:

This is the C-style way of doing it (I prefer this style):

Code: Select all

CColor color;
func((SDL_Color)color);

And this is the way introduced in C++:

Code: Select all

CColor color;
func(static_cast<SDL_Color>(color));

either way is fine, and it shouldn't cause any problems that dynamic casts (could) cause.

[XianForce]

They're conversion operators:

Code: Select all

//conversion operators
CColor::operator SDL_Color()
{
	//return color
	return(m_Color);
}

CColor::operator SDL_Color*()
{
	//return pointer to color
	return(&m_Color);
}

Check it out.

Thanks so much. I've been looking around my room for the disk, but I don't even remember if I ever had it. Couldn't find it on Google either, kept finding the ebook through a google search haha.

Well that's pretty nifty, you don't call the operators, it's just an automatic conversion =D.

EDIT: One more quick question.

Does this mean, I could just pass in a CColor object into any function asking for a SDL_Color, and it will do the necessary conversions? Or Would I have to do something like: CColorInstance->getColor()?

almost. You could simply pass a CColor for a function asking for a SDL_Color, howerver, this will probably, if the compiler isn't too smart (or is smart, idk how these things work all the time), be a dynamic cast, which is slower (I think) and can have unexpected behavior (again, I'm not quite sure). The better thing would be to use a static cast, which can be done one of two ways:

This is the C-style way of doing it (I prefer this style):

Code: Select all

CColor color;
func((SDL_Color)color);

And this is the way introduced in C++:

Code: Select all

CColor color;
func(static_cast<SDL_Color>(color));

either way is fine, and it shouldn't cause any problems that dynamic casts (could) cause.

Okay, thanks =D.

[qpHalcy0n]

Ya got it the other way around. A static cast would be "as close" to what is actually happening. Dynamic casts only deal w/ ptr or reference types, and even there, there's no way for the language to ensure that it's a safe operation. So its up to the programmer on that one. This is the basis for a type of RTTI is it's "elegant" handling of failure to convert a class because it's not a "complete class" of what you're attempting to convert it into.

However, the static cast is just an implicit form (in C++) of just a a regular ole' typecast. For obvious reasons, in C++ dynamic casting and static casting had to be resolved explicitly because dynamic casts only deal w/ ptr or reference types in regards to polymorphic classes (this is why it's said to be "slow").

In this particular case, the cast is defined by the operator and is perfectly safe and presumably fast (this is a very trivial casting).