The only caveat that comes to mind is that you would require a
private/public mechanism of every compiler. That holds true for all the
major platforms, though. For UNO libraries the export of only basically
three symbols (plus a plethora of compiler details) is essential because
there are likely to be duplicate symbols else and there is no easy way
to find such clashes. For the "framework" libs as you called them like
vcl, sfx2, svx the PRIVATE is "optional" in the sense that these should
still work afterwards.
So if you rely on compiler visibility exclusively, it might break one of
the less often built platfoms. If you're asking whether one comes to
mind, I don't know of any.
And one more concrete problem: you'd have to ensure that all symbols
reflected as "not exported" in the map files now actually have the
corresponding PRIVATE statement; it might be that there are some that
currently haven't owed to the fact that we have multiple mechanisms.
However we would need to avoid duplicate symbols here, too.
Just my 2 cents, pl
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
I do not think that we still have that many libs that are not
explicitly marked PRIVATE/PUBLIC on the function. So it would be only
about those few "renegade libs" that do not follow the convention.
A very important sideeffect would be that the visibility of a function
can be seen directly in the source, not by:
- the source
- the mapfile
- the makefile
- ....
That would be a huge improvement in readability.
Best Regards,
Bjoern
--
"One SVN to rule them all, One SVN to check out from,
One SVN to commit them all and on the harddisks bind them
In Las Vegas where the server lies."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
