[...] > >No, it requires a pure virtual class per distinct interface (abstract > >class). And I don't see why this would not scale. > > you should try writing ardour :)
It might be me who won't scale :) I know writing large applications is not easy. > >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 > > 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. And I was trying to say that C++ has other features for this and that friend is not the way to go. [...] > >Correct. But perhaps you are misusing the friend concept. Are these > >friend classes so closely related that they cannot use some public > >interface? > > as i said above, the interfaces are not public. they are intended to > be restricted just to the specified other classes. This means that all these classes are very tightly coupeled. > >> none of this helps with the problem erik identified. > > > >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. > > 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 think if you want to have less compilation dependencies, than the access control you say you'd like to see in C++ won't help. You'd really need abstract classes for that. This probably isn't easy but I think that it may, besides improving the compile time, make the code more readable. Also, perhaps a better seperation from the user interface code would be possible. [...] > >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 > > 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. I really don't think it is that simple. In general the layout of a class in memory is dependant on the declaration. There may be (only a) private constructor. The location of public member variables may change. No, I think the only way to have clean seperation of interface and implementation is using an abstract class. > >> 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. > > > >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). > > 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. How would I know to recompile code if none of the header files it uses have changed? Apart from the interface/implementation issue, the fine grained access control for classes based on the calling function/class name you propose seems to me not without its problems. --ms
