On Wed, 2005-03-02 at 09:26 +0100, S�ren Hansen wrote: > 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".
they're not. > 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 /pointer/ thus making ((CamelSessionClass *) session) an incorrect cast. > * 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. :-) yea, and you can... but that doesn't make it a safe thing to do. Jeff _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
