Subject: Re: [linux-audio-dev] (OT) C++ flame war
From: Martijn Sipkema (msipkema@sipkema-digital.com)
Date: Thu Feb 06 2003 - 20:24:10 EET
[...]
> >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
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 20:28:24 EET