 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Martin Vorbrodt Guest
|
Posted: Wed Oct 12, 2005 12:55 am Post subject: Policy based design |
|
|
I'm designing a Matrix class of 4x4 matrices used in computer graphics. Both
OpenGL and Direct3D can take a pointer to array of 16 floats which represent
the values in the matrix. OGL takes it in column order, D3D in row order.
Therefore row = 2, col = 3 will result in different offset into the float
array depending on the API. Here is my basic design test program:
#include <iostream>
using std::cout;
using std::endl;
class OGLOffset {
public:
inline int GetOffset(int row, int col) const {
cout << "OGL offsets (" << row << "," << col << ") = ";
return row + col * 4;
}
};
class D3DOffset {
public:
inline int GetOffset(int row, int col) const {
cout << "D3D offsets (" << row << "," << col << ") = ";
return col + row * 4;
}
};
template
class Matrix {
public:
inline int GetOffset(int row, int col) const
{ return Offset.GetOffset(row, col); }
private:
OffsetPolicy Offset;
};
int main() {
Matrix<int, OGLOffset> m1;
Matrix<int, D3DOffset> m2;
cout << m1.GetOffset(2, 3) << endl;
cout << m2.GetOffset(2, 3) << endl;
}
Now my question is this:
In this example, i use inline functions, and the matrix class has-a object
of a given offseting policy type. What i could do instead, is to have a
static member function instead, and NOT keep a copy of the policy class
inside the matrix. Which approach would be better? I can see the basic
tradeoff: inline member is probably "faster", but there is storage overhead
for having OffsetPolicy member (no class can have a size of 0, according to
the standard right?) On the other hand, static costs me 0 space overhead.
But is it slower? Does it require an additional function call (even though
the body of the static is visible)?
Please advise. I'm new to the policy based deisgn. I know STL makes
extensive use of such approaches (allocators, traits, etc). Please point me
to information (i'm in the process of reading Modern C++ Design, by
Alexandrescu), i would like to get as much info as possible on this kind
ofdesign approaches.
Thanks in advance!
Martin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
hydrajak@yahoo.com Guest
|
Posted: Wed Oct 12, 2005 4:30 pm Post subject: Re: Policy based design |
|
|
Why not inheret from the policy?
template<typename T, class OffsetPolicy>
class Matrix : public OffsetPolicy
{
};
Then write your code and call your functions. It won't compile if you
put a policy class in there that doesn't support the GetOffset
function.
A static member function sort of defeats the purpose of policy based
design.
Also, when using policy, I like to state in the docs of the templated
class what the EXPECTED interface of the policy is. Helps the poor dumb
sap that comes along later.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Yuri Khan Guest
|
Posted: Thu Oct 13, 2005 1:40 pm Post subject: Re: Policy based design |
|
|
Martin Vorbrodt wrote:
| Quote: | template
class Matrix {
public:
inline int GetOffset(int row, int col) const
{ return Offset.GetOffset(row, col); }
|
Why are you exposing GetOffset to the world? Isn't it just an
implementation detail that would be used in your operator[] or whatever
indexing solution you come up with?
| Quote: | private:
OffsetPolicy Offset;
};
Now my question is this:
In this example, i use inline functions, and the matrix class has-a object
of a given offseting policy type. What i could do instead, is to have a
static member function instead, and NOT keep a copy of the policy class
inside the matrix. Which approach would be better? I can see the basic
tradeoff: inline member is probably "faster", but there is storage overhead
for having OffsetPolicy member (no class can have a size of 0, according to
the standard right?) On the other hand, static costs me 0 space overhead.
But is it slower? Does it require an additional function call (even though
the body of the static is visible)?
|
You can inherit from the policy, either publicly, protectedly or
privately, depending on whether your clients and derived classes (if
any) have any business accessing your GetOffset implementation detail.
I guess they don't, so I'd use private inheritance. This also makes
more sense because Matrix is-not-an OffsetPolicy but
is-implemented-in-terms-of it.
On the other hand, you can make OffsetPolicy have a static inline
member function GetOffset, and have Matrix access that function using
OffsetPolicy::GetOffset(row, col) syntax.
In both cases, you have no size overhead (if your compiler is smart
enough to support empty base class optimization), and no speed overhead
(because all function calls involved are inline).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
mlimber Guest
|
Posted: Thu Oct 13, 2005 11:04 pm Post subject: Re: Policy based design |
|
|
[cross-posting deleted]
Yuri Khan wrote:
[snip]
| Quote: | In both cases, you have no size overhead (if your compiler is smart
enough to support empty base class optimization), and no speed overhead
(because all function calls involved are inline).
|
This cross-post was a repost from comp.lang.c++, and there was more
discussion there the first time around:
http://groups.google.com/group/comp.lang.c++/browse_frm/thread/8cbf36e0110dcc68
On your comment above, I would note that, according to Alexandrescu and
Held, not many compilers are in fact smart enough to do the empty base
optimization. There is further discussion of and a trick to get around
the problem in their article "Smart Pointers Reloaded" in the section
entitled "Size Does Matter"
([url]http://www.cuj.com/documents/s=8890/cujexp0310alexandr/alexandr.htm)[/url].
Cheers! --M
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
mdlinux7@yahoo.co.in Guest
|
Posted: Sun Oct 16, 2005 9:43 am Post subject: Re: Policy based design |
|
|
| Quote: | A static member function sort of >defeats the purpose of policy >based design.
|
Could please elaborate more on this ? As per my understanding, static
member functions of TTP [template template parameters] plays an
important role in policy based designs.
The following links demonstrate static member functions usage in policy
based designs.
Am I going wrong in my understanding? Please explain.
Regards
Dinesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
mdlinux7@yahoo.co.in Guest
|
Posted: Sun Oct 16, 2005 4:14 pm Post subject: Re: Policy based design |
|
|
Sorry I forgot to send link :
http://www.gamedev.net/reference/articles/article2054.asp
Regards
Dinesh
[email]mdlinux7 (AT) yahoo (DOT) co.in[/email] wrote:
| Quote: | A static member function sort of >defeats the purpose of policy >based design.
Could please elaborate more on this ? As per my understanding, static
member functions of TTP [template template parameters] plays an
important role in policy based designs.
The following links demonstrate static member functions usage in policy
based designs.
Am I going wrong in my understanding? Please explain.
Regards
Dinesh
|
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
|
|
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 vote in polls in this forum
|
|