6 Feb
2003
6 Feb
'03
2:33 p.m.
[...]
It might be me who won't scale :) I know writing large applications is
not easy.
And I was trying to say that C++ has other features for this and that
friend is not the way to go.
[...]
This means that all these classes are very tightly coupeled.
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.
[...]
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.
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
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 :) 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. 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. 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. 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. >> 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.