Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!pacbell.com!decwrl!fernwood!oracle!news From: gstein@oracle.com (Greg Stein) Newsgroups: comp.std.c++ Subject: Re: "packed" objects (Oops! Forgot something!) Message-ID: Date: 1 Aug 90 02:46:10 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> <6786@netxcom.DHL.COM> Sender: news@oracle.com Organization: Oracle Corporation, Belmont, CA Lines: 54 In article <6786@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes: > In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > >* Introduce an explicit keyword "packed" or similar. Declaring a base class > >"packed" turns off field ordering restrictions in that class and its > >derivatives, as well as representing a directive to the compiler that small > >size is to be preferred to fast access. Possibly vtable ptrs could also > >be replaced with smaller type tags in such classes.... > > Any derivative that uses a 'packed' class, but is not itself packed should > be flagged in the compiler with at least a warning message. The user of the > base class might not realize that it was packed! In fact, you might declare > such useage an error and REQUIRE the user to explicitly mark the new class > as packed. > > [disclaimer: this posting respresents the opinions of an individual C++ user] Nope. The derivative class would tack all of its fields onto the end rather than mixing them in. You would end up with a structure that is initially packed with unpacked stuff at the end. This should be quite allowable. Where you will get into trouble is if you try to derive a packed class from an unpacked class. This should definitely be an error. This is cuz you don't want the subclass to try packing itself into the parent class. --- That was an argument from a purely theoretical standpoint. I think packed classes are dumb. You should be able to guarantee the ordering somewhat. You would have some really nasty rules to define for things like structures within the class, bit fields that are to be packed as a unit rather than mixed in, etc. The original poster said that these would be good for avoiding things like defining funny bit fields that are shared by subclasses and such. I would state that a correct implementation of a shared bit field array can be accomplished quite nicely and straightforward through a combination of inline methods for accessing the bit fields. The only problem you may hit is if you need to add a bit field to a superclass when some subclasses have already used some (i.e. class a uses bits 0 to 2 and subclass b uses 3 and 4; it might not be trivial to reserve an additional bit for a). I think even this can be overcome through the correct use of inline functions and a proper protocol for declaring how many bits a particular class uses. [ I can supply a rough sketch of the code necessary if somebody needs it -- I'm just too lazy to do it and I don't know C++ off the top of my head... ] -- Greg Stein -- This posting bears no relation to my employer Arpa: gstein%oracle.uucp@apple.com UUCP: ..!{uunet,apple}!oracle!gstein