> > Lot's of good points, but it was all leading up to the statement =
> > found below. There are variations but most become extremely complex =
> > my opinion, often don't pay for themselves very well even over long =
> > usage. The primary reason they don't pay off even over time, is =
> > have new people coming and going, in open source this has to be
> important in
> > my opinion, [...]
> Actually, that's an excellent point that I hadn't considered. The
> pragmatics of open source may well limit how you design your software.
> I'm not sure it's relevant to us, though. While Aqsis is gearing up =
> be a fairly complex piece of software Real Soon Now, right now I'd =
> call it "pretty tricky in places". I think that if we're very careful
> to document our support code in particular (as Jonathan has already
> done with reference counting semantics), I don't think this is an
> unsurmountable problem. It's probably better to do it "right" and try
> to ensure that people treat the abstractions with respect.
Well, as long as you balance things I agree with you. But I've run
into smart pointer *like* things which have about 50 different little
"rules" you have to know about. It was a very elegant and extremely =
thing, but the benefits didn't seem to outweigh the issues. Hell, I =
screwing up one of the rules even after a year just because you don't =
it often enough to remember it.
Not trying to argue in any particular direction here but I prefer
starting with a simple get it done system. Even better, I prefer to =
with a known set of rules before trying to come up with new ones or
modifying/breaking them for specific reasons. And of course the =
best solution, grab code that already works and does what you need. :) =
general though, it's just my feeling that Aqsis doesn't need anything =
that complicated, hence I suggest the basic COM style ref counting with =
couple simple utility templates to ease repetitive implementation.
> I think a software developer as something like a lawyer. A lawyer
> in Belgium and a lawyer in Britain do pretty much the same things,
> and pretty much the same skills are required. However, if you take
> a lawyer from Belgium and stick them in Britain, it's going to take
> them some time to become even partially productive because there's
> simply so much to know about the new environment.
> Similarly, Aqsis is already at the point where nobody, no matter how
> experienced they are at C++, is able to be fully productive on the
> project at first. There's already a lot to learn. The smart pointer
> abstraction that we choose is just another thing.
Too true. I suppose my point would be more completely defined by
saying keep it simple to start with, I haven't seen all that much in the
code which requires anything fancy. Guess I'm just hesitant to =
anything particularly complex all in one go.=20
> > Basically it comes down
> > to my belief that the more complex the system and the more rules =
> > it the more likely Murphy is to show up and bite you in the ass when =
> > least expect him, or in my business when you really can't afford him =
> > up. :(
> That's certainly true, but there's also a flip side.
> On the one hand, you don't want any more complexity than you =
> need because it's going to bite you later, it's going to increase the
> learning curve and, most importantly, because you're lazy and you =
> want to implement, test and debug any more code than you have to.
> Unnecessary complexity always comes back to bite you later.
> On the other hand, flexible, generic software is good software, and
> expending the effort now to get the abstractions right will save you
> potentially a lot of work later as you have to undo all of the tacit
> assumptions which you've littered throughout the program. Making your
> software not flexible or generic enough also comes back to bite you
> Summary: Programming is hard.
Yup, it is a tough field. I think we're pretty much in agreement
here just arguing the two sides of the same coin. It sounds like I'm a
little more hesitant to branch out into fancy systems that give you
completely generic results to start with. But you also note that that =
be evil. So, it's sounding like just a discussion of degree. :)=20
> > So, there is a high level of opinion involved here but hopefully
> > understandable opinion.
> Opinion is good. I strongly believe that programmers should care
> enough about their craft to have strong opinions. (Yes, yes, we all
> spotted the self-reference.)
> And the fact is that your advice works, and works well in practice.
> My note above about "flexible, generic software" may not actually be
> that big of a deal for Aqsis, because we actually understand pretty
> well what we're trying to implement, modulo fine details. I think
> we're pretty sure that we know in advance all of the places where our
> assumptions will be broken.
As I mentioned, I think we're on the same page here. I like
approaching the "flexible/generic" from a simplistic manner to start =
the only difference. The bare minimum I can do with the pattern that =
moving towards is what I implement, the fancy goodies come in later =
it's something I've done multiple times. Just happens I've done the
reference counting stuff multiple times. :)
> [On making AddRef()/Release() abstract virtual...]
> > The other benefit is if you interface it like the above there is a
> > way to standardize *all* ref counting behind a template to make it
> > incredibly simple to create ref counted objects without even =
> > for the most part. Basically it comes down to being able to write =
> > following:
> [code deleted]
> Damn that's clever, and it's so simple, too. You can just inherit
> the implementation of AddRef() and Release() at the lowest level of
> class which is actually instantiated. You can even choose to make
> it a multi-threaded version, or a version that supports weak
> references, on a concrete-class-by-concrete-class basis. I like it.
That's the idea, it's a bit of a trick though. The template
actually looks like this:
class tCqRefCount : public Interface
Notice that the inheritance from the "interface" is templated. So,
you can derive "interfaces" from whatever base ref counting interface =
have (CqRefCount?) and still get the auto-generated code and have safe
static_cast usage so long as you stick to single inheritance =
What's even nicer about the pattern is that you can extend it to
support everything you mention such as threading without confusing the =
of the code. For instance:
template<class Interface, class Theading=3DSingleThreaded>
Then you play the typical template games of static functions in the
Threading class which are optimized away in the SingleThreaded case or
implement mutex locking in a MultiThreaded case. Again, a bit more
complexity but the pay off is you do it in only one place, it can be
described in about one or two paragraphs, and you never touch it again =
> People take note: We should use this technique in Aqsis. It looks
> like a win/win/marginally-more-typing situation.
Hmm, more-typing? Well, I suppose if you had a concrete baseclass
implementing the refcounting, yes, a bit more typing. :) Just struck =
funny because honestly I've never used a concrete refcounting base =
took me a sec to figure out the comment.. :)
> > You can of course use a real base class, but the flexibility is
> > greatly limited. The performance/bloat hit for having 2 virtual
> > in a class is very minimal since you don't actually tend to hit
> > AddRef/Release all that often in proper "component" programming.
> Yes, the bloat/performance doesn't concern me. We're not implementing
> a Python runtime system, so the reference counting machinery is highly
> unlikely to be a bottleneck.
Oh, used badly it can/will bite you in the ass real quickly. You
probably do *not* want to use this on things like grid elements or other
relatively small short lived classes. The overhead can become a notable
problem very quickly. You get unique implementations of the refcounting
code per class, that's the bloat overhead.
As you say software engineering is a complex problem, proper usage
of reference counting is a notable subset all by itself.. :) I've been
using it in game programming for over 6 years, I know very well how bad =
can be if you don't abstract things at the proper levels. I also know =
a bitch it can be to go optimize after you've already stepped on your =
organ by getting carried away. :/
I suppose I can get on the wiki and make some notes for Jonathan if
they will help. I sent him an e-mail covering some of the difficulties =
ownership transfer's previously. Guess I could just post the entire =
that I based my CPL stuff on, could help..