Post removed.

[TheRLG]

Post removed.

[andrei25ni]

Simple yet powerful. Nice work !

[TheRLG]

Post removed.

[AndyCR]

or, even better:

Code: Select all

irr::core::rect<irr::s32> EasyRect(irr::s32 X, irr::s32 Y, irr::s32 Width, irr::s32 Height) 
{ 
    return irr::core::rect<irr::s32>(X,Y,X+Width,Y+Height); 
}

[Baal Cadar]

Or yet even better to not camoflage this with a seperate function at all. Initialise the rect directly with X,Y,X+Width,Y+Height.

Seriously, using EasyRect makes the code harder to read in the end.

[TheRLG]

Post removed.

[Baal Cadar]

Actually I proposed (and still do) to not create a seperate function at all for this task. Instead do what EasyRect does in-place. This little complexity doesn't warrant a dedicated function imho. I am all for functional decomposition, but this drives it too far.

Rationale: Source code has to be obvious. One should see on the first glance what is done. Question is, whether it is easier to read:

Code: Select all

guiEnv->addButton(rect<s32>(left, top, left + width, top + height));

or

Code: Select all

guiEnv->addButton(EasyRect(left, top, width, height));

Without prior knowledge about what EasyRect does, the code above is easier to read. Else it is equal. So you win nothing and loose a bit in this aspect.
Performance is equal when the function is inlined, less else.
Other aspects don't play a role here, imho.
So at the end of the day EasyRect usage makes the code slightly worse.

In an effort to be a bit constructive here, I propose two changes. Make it inline and make it a template function.

Code: Select all

template<typename T> inline  irr::core::rect<T> EasyRect(T x, T y, T width, T height)
{
    return irr::core::rect<T>(x, y, x + width, y + height);
}

[AndyCR]

As it turns out, rect has a constructor for position2d, dimension2d which does the exact same thing (position2d, position2d+dimension2d).

[TheRLG]

Post removed.

[xterminhate]

Avoid multiple copy, use constness/references :

Code: Select all

irr::core::rect<irr::s32> EasyRect( irr::s32 const & X, irr::s32 const & Y, irr::s32 const & Width, irr::s32 const & Height) 
{ 
    return irr::core::rect<irr::s32>(X,Y,X+Width,Y+Height); 
}

[TheRLG]

Post removed.

[Baal Cadar]

RabidLockerGnome, both are correct, though your proposed order is more common and thus to be preferred.

Anyway, I'd not use const& here. There is no positive effect whatsoever. Whether pointers are put on the stack or their contents is irrelevant here, since s32 is the same size as a pointer anyway. You also don't safe something on execution. Const references are useful, when the argument type is bigger than a pointer. Const correctness is a nice thing and can be done on the value type arguments too. Though I'd ommit those for the function prototype for readability reasons. There it doesn't matter anyway, since the function has call-by-value semantics. You can use const in the actual implementation then if you want.

[niko]

That's really useful. From time to time I wish I had decided to make the rect work with a position and a dimension rather than two positions. But when I wrote the software renderer and the gui (which was the first thing I did, before even doing D3D or OpenGL), it was better that way. But that solution is a very nice workaround.