On Wed, Feb 05, 2003 at 01:23:41PM -0500, David O'Toole wrote: for an on-topic rant, see Erik de Castro Lopo's interview on mstation.org: http://mstation.org/erikdecl.php where he discusses the OO design of libsndfile and libsamplerate (surely two of the most rock-solid audio libraries ever!) and be sure to scroll down to the second half of the interview, about test suites, for some really juicy useful hacking advice ... Conrad.

[...] "I also think that there is a real problem with the way classes are defined in C++ and this is a problem which really does impact design. The problem is that you are forced to define the private data members and functions at the same time as the public ones. This is OK for the trivial C++ examples you see in textbooks but as soon as you REALLY want to hide the private information you end up defining the class to have a single private void pointer which gets something allocated to it in the implementation. This is basically the same thing you do when doing OO programming in C, so where is the benefit of C++?" -- You are not forced to define the private data members and functions at the same time as the public ones in C++. The way to handle this is to put the public interface in a pure virtual class: class animal { public: virtual int legs() = 0; // returns number of legs the animal uses when moving around }; and then derive from that interface: class dog : public animal { public: int legs() { return 4; } }; I think most of the arguments in the article are not valid, but I guess I really shouldn't be making my point here on this list. It can't hurt for to also hear some positive comments on C++ occasionally though... --ms

the the public members I don't see what makes the method I propose, and that most C++ programmers use, ugly. It is much cleaner and explicit that your method below. You cannot create an Object on the stack. With C++ classes you can. This makes resource management much easier. This is not type safe. I suppose this function method_1 then calls another function via a pointer stored somewhere in *object? void Object_delete(Objects *object); ? I think it is less flexible, less readable and error prone. Hmm. I tend to think it's the other way round. (the standard "C++ is slow", "C++ isn't really OO", etc. arguments are quite often seen.) I meant only the ones related to C++. [...] Sure. But the language does not support it, it merely enables its use. It is not up to me to tell you what language to use. As you in your article talked how you think C is a better language, I gave my point of view. --ms

i love C++. i think its one of the best things ever. but i happen to agree with Erik. the solution proposed by martijn doesn't scale well, and doesn't really address the issue in a comprehensive way. it requires one pure virtual class per distinct set of private members, for a start. the kinds of problems i have with C++ stem from the fact that you cannot mark a section of protected members as accessible from only a particular set of friends. the only way to say "only class Foo can access these member (functions)" is to create a separate class, make Foo a friend of that class, and then inherit from it. this gets really messy really soon. the editor object in Ardour contains many distinct sets of functionality that i would really like to partition. i could create a set of discrete classes that cover each aspect of the functionality, and then do MI from all of them. the problem is that is each one of these aspects *internally* needs to know about the others, which now means that they each have to be friends of each other. so what's the point? i'd end up with something ludicrous like: class EditorFoo { ... protected: friend class EditorThis; friend class EditorThat; friend class EditorTheOther; ... friend class ObjectThatInteractsWithEditorFoo; ... }; ... class Editor : public EditorFoo, EditorThis, EditorThat, EditorTheOther .... { } which is really no help at all. the other alternative is to use HAS-A instead of IS-A, and its even worse. we end up with lots of code like: editor->foo->... editor->that->... editor->theother->... all i'd really like it to be able to say: class Foo { protected: /* scope A */ friend class Bar; ... protected: /* scope B */ friend class Baz; ... }; such that Bar can only access stuff within "scope A" and Baz can only access stuff in "scope B". that is, access control keywords ("private", "protected", "public" define access scopes). right now, a friend class declared anywhere within the class declaration is a friend, period. none of this helps with the problem erik identified. i would really love a C++ that did this: class Foo { public: ... stuff ... private: <some tokens that meant something like #include> }; and then in other files, you would do: #use "foo.h" or #implementation "foo.h" or something like that. the first one would just bring in the public declarations, and its what you'd use when you're calling or creating Foo objects. the second one would be used in the definitions for the member functions of Foo, and hence would almost certainly be limited to "foo.cc". note that the private stuff would be in a file that looked just like the class declaration, but had no public (and protected?) declarations. in other words, the class declaration it includes is implicitly 100% private, but it can include header files that are necessary for the private declarations. just dreaming. --p

[...] No, it requires a pure virtual class per distinct interface (abstract class). And I don't see why this would not scale. This really is a different problem. A friend is just like a member function, i.e. it can access the class' private data, but it is not in the class' scope and the function is not invoked on an object. Declaring a class A friend of another class B is saying that all member functions of A have access to the private part of class B. This should only be done to exporess closely connected concepts. When possible other classes should interact using a class' public interface(s). So, derive from various abstract classes that provide interfaces for these sets of functionality. Here EditorFoo is not a abstract class. class A { // some interface public: virtual void a() = 0; }; class B { // another interface public: virtual void b() = 0; }; class editor : public A, public B { // the editor provides both interfaces public: void a(); void b(); }; and now a class C that wants to use the functionality of the editor that is exported by interface A can use it like: void f(A& i) { i.a(); } without depending on the implementation. Note that your problem is still different as with using friends in such a manner the classes using the editor are dependant on its implementation and also don't use the editor's public part only. This is an option. Correct. But perhaps you are misusing the friend concept. Are these friend classes so closely related that they cannot use some public interface? The problem Erik identified was that one could not seperate the interface from the implementation in C++. I then said this can be done using an abstract class, i.e. an interface. It doesn't work that way. You cannot create an class instance without its full declaration. I don't see the problem of having the private part of a class in the header. If you want to be seperated from the implementation, use an abstract class. But then you cannot create a class instance, you can only use the provided interface on an already created instance (, but you can delete it when there is a virtual destructor in the interface). I don't see what this would solve and I don't think this is even possible. Changing the private part will break binary compatibility (without changing the public header). --ms

you should try writing ardour :) i know what a friend *is* - i was trying to convey what i want a friend to be in the best of all possible worlds. the point is that i want semi-public interfaces that are not implemented via abstract classes or inheritance because they cover functionality that is still tightly coupled to the rest of the object. by making them abstract, i can solve the coupling at the implementation level (because the implementation only exists in the concrete classes). but i still find this really messy. conceptually, i am not creating a distinct type of object - i want to provide a particular set of objects with access to a limited set of member functions belonging to an otherwise unified object. C++ won't let me do that - it forces me to use an abstract class, multiple inheritance and virtual functions to get the job done. being able to limit the scope of a friend declaration would solve this problem in a much more natural way, i think. this is precisely the solution i find so cumbersome. an editor is not an A, and a B and a C and a D. its an editor. the point is that only certain other things should be able to call a() and other things should be the only ones to call b(). its very unnatural to declare this in this way, although yes, i know that it works. as i said above, the interfaces are not public. they are intended to be restricted just to the specified other classes. i would accept that this is true for relatively simply objects. i just don't think it scales well. the current ardour editor has about 7000 lines of code, the object itself has about 800 members (either data or functions). splitting this up is a non-trivial exercise. nevertheless, it could truly be worth doing. the compilation dependencies right now are horrendous. changing editor.h requires me to wait about 10 minutes for a recompile :) i don't believe that this is true. the actual code executed by constructor is the only thing that needs to know the full declaration. the one exception is creating objects on the heap, where we need a size so that we can allocate memory, and then run the constructor using the returned address. i'd be happy with a language where x = new Foo; really translates to: x = Foo::constructor (malloc (Foo::sizeof()); where ::sizeof() is a built-in compiler-generated virtual. the dependency part is easily solved by the compile system. given the new preprocessor directives it would require anyway, you'd just generate dependencies that included the private part. then if the private part changes, even though its never read by the users of the public interface, they are recompiled too. anyway, its water under the bridge. C++ doesn't do this, and will likely never do this. --p

Paul Davis wrote: But one point with this pure-abstract-base-class-as-interface line of thought is that you don't have to be describing an "is-a" relationship at all, you might be simply using the interface to express exactly what you're describing above: that there is a subset of the functionality provided by a particular class that may be of interest (as a bundle of related methods) to someone else. In other words, you aren't saying that your editor is an A, a B, a C and a D. You're just saying that it provides some interfaces that are described in A, B, C, and D. That doesn't help with your access protection problem, and it doesn't necessarily help at all if your other code actually needs various combinations of the things in A, B, C and D, but in principle -- and often in practice -- it can be a pretty tidy expression of what you intend. That said, I tend to just lump everything together and forget about it, myself. I count 270-odd members and nearly 5000 lines of code in Rosegarden's NotationView class (which doesn't even do the hard stuff, it just sets up the window and manages the menu functions) and that only has one abstract base -- with a single method in it! -- and one strictly implementation non-abstract one. In fact it's such a mess that I think I'll stop talking about conceptual shit like this right away because I clearly don't know what I'm talking about. *cough* Chris

they are. in fact in some cases, they started out as private classes of the Editor itself. when they were moved out (for greater compilation independence), they ended up as friends because, as stroustroup notes, private class types are just implementation aids, not conceptually distinct objects. hence, the TrackView class is a full bona-fide friend of the Editor. well, it was. that's all about to change as the nature of the problem has changed and/or become more visible, and we can now see that a TrackView is not really just an implementation aid but something more standalone than that. well, the editor is *only* about user interface. everything in ardour/gtk is about user interface. there is no back-end there at all - thats all part of libardour. the editor defines policy (which mouse actions cause which operations), it defines how undo/redo is done, and is controls drawing during and after operations. it doesn't contain any implementation of any operation at all. so i think there is almost total separation already. remember: there is complete and enforced separation of UI and backend in ardour. no part of the backend knows about any kind of UI at all. i know its not unique in this sense, but it just bears repeating. --p

[...] And the offset of its members. [...] When dynamically linking C++ classes that imlement an interface you can export create/destroy functions that return/take a pointer to a instance. Note that you should not use virtual destructors instead of a destroy function since the delete function called might not match the new from the dynamically loaded code. On of the best things about C++ is having auto storage classes, since it makes resource management much easier/safer. I really don't like Delphi/Object Pascal at all. I'm not sure but I believe with Java it is also not possible to create classes on the stack, but Java has a garabage collector (and that's not always convenient for RT tasks). --ms