Am 07.01.23 um 10:32 schrieb Damjan Jovanovic:
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.
I did not think about java integration. Good point!
The main/tools String with its 16 bit length, saves space for the large
number of strings in Calc cells.
I am not sure what you mean. mnLen is sal_Int32 and Sal_char is 8 bit.
rtl/strbuf uses almost the same data structure. Maybe I miss something?
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.
I have look on those. Thanks.
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.
I'll have a look on those, too.
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.
Thanks for your feedback!
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
