On Sat, Jan 7, 2023 at 9:51 AM Peter Kovacs <pe...@apache.org> wrote:

> Hi all,
>
>
> I have an emotional issue and I need some help.
>
> I think the classes mentioned in subject are all crap. They are all ugly
> and I do not want to use any of them.
>
> I would like to remove them. And replace them with
>
>
>   std::basic_stringstream
>
>
>   std::string
>
>
> But this is a huge and fundamental change. What I would like to do is to
> hollow out the classes we use, one by one, until everything is using std
> classes or can cast to. Then remove the now obsolete classes within the
> code.
>
> any objections?
>
>
Hi

Please leave them alone. They all have their purpose, and they work in very
specific ways to accomplish their tasks.

The main/tools String with its 16 bit length, saves space for the large
number of strings in Calc cells.

The main/sal OString and OUString are 32 bit and copy-on-write, like Java's
java.lang.String. Also UNO serializes to and from OUString for C++.

I do agree that string type changes will be necessary in some cases. For
example if we want to increase our 16 bit limit on maximum paragraph size
to 32 bits, we will probably have to change the tools String to a longer
string type.

The real crap classes that should be replaced ASAP are the 16 bit main/svl
PTRARR, which I replaced in 2 places in
https://github.com/apache/openoffice/pull/164, but which is used in another
53 places (
http://opengrok.openoffice.org/search?project=trunk&full=SV_DECL_PTRARR&defs=&refs=&path=&hist=&type=&si=full).
Many 16 bit limits come from that class. And I now discovered another 22
usages of SV_DECL_PTRARR_SORT. The problem is, that has many knock-on
effects, as is clear from the size of my PR.

We also have a bunch of primitive pre-STL main/tools classes like Container
and List, written around 1994 and generally not very good at anything,
including performance.

Yes, the way C++ is used in OpenOffice is unusual and foreign to everyone.
But eventually it makes sense. Start with one of the more recently
developed modules, like the OOXML filter in main/oox, or the Base
application in main/dbaccess, which were written closer to 2010 and are
much cleaner, easier to read and understand, use STL containers, etc. I've
been improving that OOXML filter lately and could help you get started.

Regards
Damjan

Reply via email to