whisd@sersun1.essex.ac.uk (Whiteside S D B) (06/03/91)
I wonder if anyone has any suggestions on this: Modula-2, for example, provides a separate "public" interface to the user's of a module. The "definition module" is like a header file - it shows what functions are available to the user, but it need not show private functions nor the design of the data structures it uses. In C++ you have private/public/protected members, but the header file must contain reference to all these things, regardless of whether the user needs to see them or not. This means: i) security might be compromised: it's possible for the user to "hack" into the data structures ii) when implementation-specific features are changed (such as, in a recent case with me, where I wanted a different sized array in my class) which do not change the semantics of the class, the user has to be recompiled as it has access to the same information as the class itself. iii) The user is burdened with too much detail when using the header file as a documentation aid. Can these be overcome with existing C++ constructs? Or would a change in the language allowing "incomplete" class declarations for public header files be needed? Thanks for any comments. Simon Whiteside
jbuck@forney.berkeley.edu (Joe Buck) (06/04/91)
In article <5243@servax0.essex.ac.uk>, whisd@sersun1.essex.ac.uk (Whiteside S D B) writes: |> Modula-2, for example, provides a separate "public" interface to the user's |> of a module. The "definition module" is like a header file - it shows |> what functions are available to the user, but it need not show private |> functions nor the design of the data structures it uses. |> |> In C++ you have private/public/protected members, but the header file |> must contain reference to all these things, regardless of whether the |> user needs to see them or not. |> |> This means: |> i) security might be compromised: it's possible for the user to "hack" into |> the data structures Stroustrup said something about this: the member access system is designed to protect against accidents, not maliciousness. Someone determined to defeat the type system wouldn't find it much harder to do with Modula-2. |> ii) when implementation-specific features are changed (such as, in a recent |> case with me, where I wanted a different sized array in my class) which |> do not change the semantics of the class, the user has to be recompiled as |> it has access to the same information as the class itself. There are several ways to get around this. You can have pointers or references to class objects even with incomplete type definitions; if you'd used a pointer rather than an array in your class you could have had the same semantics and not required recompilation. Example: class FooGuts; class Foo { private: FooGuts *guts; public: // a buncha members here }; There's a cost to this: an additional level of indirection. |> iii) The user is burdened with too much detail when using the header file |> as a documentation aid. I don't think headers should be relied on for documentation; they aren't sufficient for some purposes and provide too much detail for others. |> Can these be overcome with existing C++ constructs? Or would a change in the |> language allowing "incomplete" class declarations for public header files |> be needed? How could you perform separate compilation with an incomplete class declaration? If I say #include "Foo.h" ... Foo bar; I have to know, at minimum, how big Foo is to allocate the space for it. If there are inline functions I must know a lot more. |> Thanks for any comments. |> |> Simon Whiteside -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
schwartz@groucho.cs.psu.edu (Scott Schwartz) (06/04/91)
jbuck@forney.berkeley.edu (Joe Buck) writes:
Stroustrup said something about this: the member access system is designed
to protect against accidents, not maliciousness.
An then on page 253 gives an example of language features designed to
prevent maliciousness (noninheritance of friendship), using an example
named "class Spy".
Someone determined to defeat the type system wouldn't find it much
harder to do with Modula-2.
That's no excuse for encouraging it.cep@Apple.COM (Christopher Pettus) (06/04/91)
In article <5tdHm72m@cs.psu.edu> schwartz@groucho.cs.psu.edu (Scott Schwartz) writes: > >jbuck@forney.berkeley.edu (Joe Buck) writes: > Stroustrup said something about this: the member access system is designed > to protect against accidents, not maliciousness. > >An then on page 253 gives an example of language features designed to >prevent maliciousness (noninheritance of friendship), using an example >named "class Spy". Stroustrup's choice of words in this example is exceptionally poor, but the issue is the same: it would be easy to violate the purpose of protected and private if friendship was inherited (at least that's his point; IMHO, it's being overly conservative). The _real_ reason is, of course, the same: without full compiler access to the class definition, it's size could not be determined, which violates the classes-as-primitive-types goal of C++ (which is a worthy one). -- Christopher Pettus -- Object-Based Systems -- Apple Computer, Inc. MS 3-PK -- (408) 974-0004 -- cep@apple.com -- Link CHRISTOPHE "Don't let your .h write no check that your .c can't cash."
philip@pescadero.Stanford.EDU (Philip Machanick) (06/04/91)
In article <5tdHm72m@cs.psu.edu>, schwartz@groucho.cs.psu.edu (Scott Schwartz) writes: |> |> jbuck@forney.berkeley.edu (Joe Buck) writes: |> Stroustrup said something about this: the member access system is designed |> to protect against accidents, not maliciousness. |> |> An then on page 253 gives an example of language features designed to |> prevent maliciousness (noninheritance of friendship), using an example |> named "class Spy". |> |> Someone determined to defeat the type system wouldn't find it much |> harder to do with Modula-2. |> |> That's no excuse for encouraging it. I'm not really sure this Modula-2 comparison is valid. In C++, the mechanism for information hiding between separately compiled modules is really statics (which cannot be seen across compilations). Classes are a finer-grained mechanism, provided more for abstraction than security in the anti-malice sense. I imagine a lot of Modula-2 modules are more like a single C++ file containing lots of classes, than like one C++ class. Otherwise, managing compilation and dependencies is too complicated. (Are there people who make one file per class / data abstraction?) Whether the Modula-2 mechanism is better is another matter, but let's compare like features if we are going to compare anything. -- Philip Machanick philip@pescadero.stanford.edu
djones@megatest.UUCP (Dave Jones) (06/04/91)
From article <5243@servax0.essex.ac.uk>, by whisd@sersun1.essex.ac.uk (Whiteside S D B): > I wonder if anyone has any suggestions on this: > > Modula-2, for example, provides a separate "public" interface to the user's > of a module. [... but not C++, which means ... ] > i) security might be compromised: it's possible for the user to "hack" into > the data structures Don't worry about it. You can't save the world from incompetent hackers. Besides, there may come a day when you need to hack into a private data structure as a stop-gap measure while you wait for a vendor or coworker to fix a buggy library class. > ii) when implementation-specific features are changed (such as, in a recent > case with me, where I wanted a different sized array in my class) which > do not change the semantics of the class, the user has to be recompiled as > it has access to the same information as the class itself. The compiler (or a "smart" linker) *uses* that info to size the structure. If that's not what is wanted, the implementer should write the class so that the array is sized and created by the class's methods, particularly constructors. You can have it either way, you just have to know with way you want it. > iii) The user is burdened with too much detail when using the header file > as a documentation aid. Perhaps, but we can live with that. I would usually prefer too much info to too little. If (heaven forbid!) there is a bug in the implementation of the class, access to the private declarations of the class may be the ticket to figuring out what is wrong. > Can these be overcome with existing C++ constructs? I don't think you've named any problems that really need to be "overcome", but you can do the things you want using plain old C++.
steve@taumet.com (Stephen Clamage) (06/04/91)
cep@Apple.COM (Christopher Pettus) writes: >The _real_ reason is, of course, the same: without full compiler access >to the class definition, it's size could not be determined, which >violates the classes-as-primitive-types goal of C++ (which is a worthy >one). The compiler needs to know more than the class size. The offset of a public data member depends on all previous data members, and the index of a public virtual function depends on all previous virtual functions. So code which references only public members of a class in general still needs to include a complete class declaration. One can argue about the merits of this feature of C++ language design, but partial class definitions are nevertheless not allowed. -- Steve Clamage, TauMetric Corp, steve@taumet.com
denisb@leland.Stanford.EDU (Denis Bohm) (06/05/91)
A very simple way to really make something private is to hide those
private variables into a struct that is not defined in the public
header file (this also lets you change the hidden state store in
the class without having to recompile clients that use the class):
foo.h:
------
class foo {
struct foo_hidden* hidden;
public:
foo();
};
foo.c:
------
#include "foo.h"
struct foo_hidden {
int hidden_variable;
};
foo:foo()
{
hidden = new struct foo_hidden;
}
Denis BohmJohn.Montbriand@weyr.FIDONET.ORG (John Montbriand) (06/05/91)
well, I think I'd disagree with you there. I think I have a pretty good idea of what modula-2 is like (I've written 1 30k line program) and no doubt, it's a great language because of the way it allows you to hide data, but it does NOT allow '"incomplete"' declarations of any kind. Sure, it allows you to use opaque types, but it's strictly a question of ALL or NONE--either the user get's to see the record components or she doesn't. I s'pose the open array types for procedure parameters are the only thing I really miss (just because they're convenient and do a bit of type checking), but you can simulate the exact same thing using pointers. later, John....... -- John Montbriand - via FidoNet node 1:140/22 UUCP: ...!herald!weyr!John.Montbriand Domain: John.Montbriand@weyr.FIDONET.ORG Standard Disclaimers Apply...
al@well.sf.ca.us (Alfred Fontes) (06/05/91)
whisd@sersun1.essex.ac.uk (Whiteside S D B) writes: >In C++ you have private/public/protected members, but the header file >must contain reference to all these things ... >iii) The user is burdened with too much detail when using the header file >as a documentation aid. This can be avoided to a certain extent by putting the public members at the top of the class definition, followed by protected and finally by private members. This saves the user from having to look at the private stuff. If you have inlines, they can immediately follow the end of the class definition. Al Fontes, Jr. al@well.sf.ca.us
warsaw@nlm.nih.gov (Barry A. Warsaw) (06/05/91)
>>>>> "Alfred" == Alfred Fontes <al@well.sf.ca.us> writes: Alfred> This can be avoided to a certain extent by putting the Alfred> public members at the top of the class definition, Alfred> followed by protected and finally by private members. Alfred> This saves the user from having to look at the private Alfred> stuff. If you have inlines, they can immediately follow Alfred> the end of the class definition. This is a Really Good Suggestion. I'll second that, as this is the C++ coding style we've adopted and have been using for several months. Explicitly stating whether something is public/private/protected is also a good habit to get into, I think. And separating out inline functions also helps with header file readability. Example follows siggy. -Barry "When in doubt, cout." -------------------- cut here -------------------- // foo.h class foo { public: foo( int num ); inline int number( void ); // get inline void number( int num ); // set protected: virtual int valid( int num ); private: int priv_number; }; inline int foo::number( void ) { return( priv_number ); }; inline void foo::number( int num ) { if( valid( num )) priv_number = num; }; // foo.cc foo::foo( int num ) { ... }; // etc...
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (06/10/91)
warsaw@nlm.nih.gov (Barry A. Warsaw) writes: >>>>>> "Alfred" == Alfred Fontes <al@well.sf.ca.us> writes: > Alfred> ... If you have inlines, they can immediately follow > Alfred> the end of the class definition. >This is a Really Good Suggestion. I'll second that, as this is the >C++ coding style we've adopted and have been using for several months. >... >// foo.h >class foo >{ > ... >inline int foo::number( void ) >{ > return( priv_number ); >}; Oddly enough, this can produce multiple definitions of int foo::number (void); with BC++, if you have "out of line inline functions" enabled. It will literally create a copy of the function in each module compiled. The solution I found was to turn off this option, or to use static inline int foo::number (void) ... Is the need to specify static a compiler anomaly or a language ambiguity? Of course, if you want it to be a static function (referencing no class members), you get something like: static inline static int foo::number(void); -- Kevin Kleinfelter @ DBS, Inc (404) 239-2347 ...gatech!nanoVX!msa3b!kevin Dun&Bradstreet Software, 3445 Peachtree Rd, NE, Atlanta GA 30326-1276
pete@borland.com (Pete Becker) (06/10/91)
In article <1667@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >warsaw@nlm.nih.gov (Barry A. Warsaw) writes: >>// foo.h >>class foo >>{ >> ... >>inline int foo::number( void ) >>{ >> return( priv_number ); >>}; > >Oddly enough, this can produce multiple definitions of > int foo::number (void); >with BC++, if you have "out of line inline functions" enabled. >It will literally create a copy of the function in each module compiled. While that statement is true, it's not complete. When you select out of line inline functions (which is the default when you generate debugging information), each .OBJ gets a copy of each of the inline functions that it uses. But the linker only pulls in one of those definitions, so there's only one copy in the resulting executable file.