Re: C# Properties, inner classes and CRTP
Hmm, most of what i can do is repeating my other posts. The main issue
is replacing CRTP and offsetof with built-in syntax. So the following
questions arise:
1) Are CRTP / offsetof justified?
Is there a significant number of possible situations where using CRTP
or offsetof is justified?
Here it's not talking about my examples alone, but the general case.
Serious examples are usually complicated, but it is a known experience
they exist. If you show how CRTP is not necessary in my examples, this
does not discard it as a common and justified practice.
The offsetof question is frequently asked in forum discussions, so
obviously there is a need.
At home I am experimenting on a 'universal' data structure for
polygonal meshes of arbitrary dimension (subdivision of an n-manifold
into cells of dimension 0..n). There you have all the requirements we
are discussing here: every additional reference, every vtable pointer,
every virtual function lookup hurts.
A more common example for the offsetof stuff is the state machine in my
first post. It has only two states, but the principle allows a machine
with an arbitrary number of states (known by the programmer), and
additional shared data (like arrays, etc). Here the offsetof trick is
quite useful to avoid unnecessary references. But you will also agree
that adding a new state by copy+paste can easily lead to mistakes - the
offsetof macro needs to get exactly the name of the state, and in case
you use reference, you need to initialise all the references in the
constructor of the state machine.
2) Performance benefit of CRTP and offsetof?
Do CRTP and offsetof give us a significant performance benefit (time
and space), compared to other solutions like virtual functions, or
explicit references? I'd say yes, especially when dealing with small
classes where the vtable pointer or explicit references would lead to
50% or more increase in size. And for small functions where vtable
lookup has a significant impact on the time performance.
3) Elegance of CRTP and offsetof solutions?
Do CRTP and offsetof give us elegant solutions, are they easy to teach
and understand?
I like CRTP, but I think it is not easy to teach and understand.
Especially, if your project is bloated with templates anyway, you will
be happy to have one less. In the end, I would say CRTP is a nasty
workaround.
And a macro like offsetof is nasty and not even typesafe.
Imagine you have 10 nested objects, all with a different type (for
instance, if you decide to implement a state machine in the way I
suggested - with additional shared data that justifies using offsetof).
Now for each of these nested objects you either need to store a
reference, or re-write the offsetof trick. Now imagine you add one of
these objects - you will most likely mess that up.
4) New language feature justified?
Is it benefitial / necessary / justified to replace CRTP and offsetof
with reliable and built-in language features? I think you can guess my
answer :) but that's the matter of discussion in this thread.
5) What is the best solution?
Is my proposal really a satisfying solution? Are there alternatives?
I'm all interested!!
6) Positive/Negative side effects of a proposed solution?
Given a proposed solution, does this solution even solve other
problems? Does it allow a new programming style?
Well, I think a language feature like fragmental classes would enable
the inexperienced programmer to create CRTP-like compile time
polymorphism architectures, and to read and understand such code
written by other people.
Libraries like STL or boost could provide fragmental classes to derive
from without too much thinking. Or do you want the general programmer
to derive from a CRTP ? Imagine the crtp has more than one template
parameter - now the client needs to find out which parameter gets the
type of the derived class.
Dave Harris wrote:
stroumpf2004-gtalk@yahoo.de () wrote (abridged):
Problems:
- Performance overhead because of vtable lookup that is not nessecary
from a technical perspective.
Given that it's not necessary, are you sure a good compiler can't just
optimise it away? In the line:
c.angle += 180; // -> c.angle_ == 135
the exact type of c.angle is known. The call to Float::operator+=() can be
inlined. We can propagate knowledge of the type of c.angle to the inlined
body, and use it to dispatch the calls to get() and set() statically.
We can optimize away the call, but not the vtable pointer. But it seems
you are right, as long as anything is inlined.
Alternatively, as your second example shows, we can just use the CRTP.
Yes.
Your 1.2 code slightly muddies the issue by mixing in a second
optimisation to avoid the enclosing_object pointer. If we drop that, the
code isn't so unclear.
This would mean you consider CRTP a reader-friendly solution. If we
accept that as a general statement, this kills the main argument for
fragmental classes. The only remaining benefit would be the the benefit
when deriving from multiple classes with virtual functions.
(In any case it seems to me that the concept of an
Angle in degrees is reusable and doesn't need to be defined in-place.
Keeping different concepts separate helps clarify the code.)
class Angle : Float<Angle> {
float &angle_;
public:
Angle( float &angle ) : angle_(angle) {
}
void set(float f) {
while(f>=360)
f -= 360;
while(f<0)
f += 360;
angle_ = f;
}
float get() {
return angle_;
}
};
class C {
float angle_;
public:
C() : angle(angle_) {
}
Angle angle;
};
Here we have no virtual functions. I don't think the code is hard to read,
given what it does. The overhead is the reference Angle::angle_. Even that
could be eliminated if we didn't need the angle_ to be shared.
Well, if we don't need to share there is no need for offsetof or CRTP
anyway - no surprise. Let's instead just assume there are cases where
we want to share.
2.3) The "enclosing_object" keyword. This keyword returns a pointer to
the enclosing object. Technically, this can work in two ways:
- for member classes that are defined as "nested", the
"enclosing_object" keyword will just return the hidden reference.
I don't think this adds much benefit over using a reference manually.
I have used Java, which works a bit like that, and it just seemed to
obscure what was going on without helping me do anything new.
Agreed, that's a matter of taste. I liked that when using Java. And I
don't see why it would be bad to have that possibility. My first idea
was this offsetof thing, but I thought once we start that, we can also
go on and provide a more general way to get the enclosing object.
- for anonymous member classes defined in the first way (2.1 [*]), the
"enclosing_object" keyword uses a mechanic that is equivalent to the
offsetof macro trick. The anonymous definition guarantees a fixed
adress difference to the enclosing object.
Although I am more sympathetic to this, it seems to be hedged around with
restrictions. The struct has to be anonymous, it can't be reusable, it
can't even be used for multiple member variables within the same class. It
all seems a bit messy and inelegant.
Restrictions like that are necessary. If you want to use offsetof, you
need to guarantee that the nested class has only one instance, as a
member of its enclosing class. The offsetof macro, btw, does not
guarantee anything, which can likely lead to errors.
If you want to reuse the struct, you need to create subclasses for each
occurance - or you can't use an offsetof-like mechanism.
I think I'd rather have a more rigorous way to encapsulate the offsetof
trick. Perhaps some kind of based pointer.
Well, I am happy for any kind of suggestions. The condition is that
your proposal still allows my big state machine example!!
{ Quoted signature and clc++m banner removed. -mod }
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]