[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: exporting symbols (was Re: The goodness of goodness)
From:       Michael Matz <matz () kde ! org>
Date:       2001-05-29 11:15:24
[Download RAW message or body]

Hi,

On Tue, 29 May 2001, Dirk Mueller wrote:

> All we can do is try it. such a parser can't be too difficult. should we
> start with kdoc or with dcopidl ? :)

I wanted to originally base it on dcopidl to accept something like this
syntax:

class KDE_PRIVATE MyClass:public BaseClass,private PClass {
...
};

to make all symbols resulting from class MyClass non-public;

class Bla {
public:
  KDE_PRIVATE int internal_method (int whateever);
};

to make this one method non-public, and:

class Blubb {
public:
KDE_START_PRIVATE
  int method1();
  void another_method();
KDE_STOP_PRIVATE
  int visible_method();
};

to make all methods between the obvious pair non-public.

To be compatible with C++, this somewhere needs #define'ing away the
KDE_*PRIVATE tokens.  So we don't need to process comments.

One problem which needs thought is: what happens with inherited symbols?
The most simple (and arguable most correct) method is to really only make
those symbols non-visible, which are explicitely mentioned, which then
means, that this is possible:
  class A {public: int m();};
  class B:public A {public: KDE_PRIVATE int m();};
and means A::m() is visible, but B::m() not, which _might_ have issues
with virtuality (what is, if m is virtual, another DSO defines a class C
based on B, and calles m().  There _should_ be linker errors, but this
needs investigation).

With regard to kdoc: the tool should be run as part of the build system,
and right now we don't require perl for a simple make, with kdoc we would.


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]