ons, 02 03 2005 kl. 09:38 +0800, skrev Not Zed: > > > And that means actually subclassing it, you can't just create it and > > > override the virtual methods manually. > > Ok, this might be more of a GObject question, but why? I realize now > > that I'm not *supposed* to instantiate it, but I don't understand that > > it fails. > It has nothing to do with GObject. It is unclear what failed, I > presume it just crashed because you didn't build a concrete class. Maybe it's just me being too much of and old school C programmer, but "abstract", "concrete", "class" and "object" are not words in my regular C programming vocabulary. Hence, I don't expect the programming langauge or compiler to make sure that I can't create "instances" of "objects" considered "abstract". Obviously, there's something I don't understand.. :-) The way I see it: * CamelSession is a struct containing some fields. * Among others, it contains a CamelSessionClass as the first field. * A CamelSessionClass is a struct containing some fields. * One of these fields is a function pointer called get_password. When I create a new object of type CamelSession, I'd expect to be able to access the get_password field, regardless of what it says in a comment at the top of camel-session.h. :-) > Well, you must also remember camel is just an internal library, it has > incomplete documentation for external use, and neither is the api > guaranteed to be stable yet. I know. I'm doing this any becuase I want to get to know Camel. It makes it easier to understand the Evolution code, I think. Also, I'm considering using camel as is, and I'm willing maintain the glue code, so it shouldn't be too much of a problem if I can understand Camel. -- Søren Hansen <sh warma dk>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature