Re: implementation language [was: library for unicode collation in C for texi2any?]

[Per Bothner]

On 10/14/23 05:36, Gavin Smith wrote:
> many might have said that Perl was a natural fit for text processing.

It probably was and is - if performance isn't a high priority.
I notice in the texinfo source how much string concatenation is going on
- and it's hard to implement that efficiently.  You need a some kind
of buffer you can append to, and only re-allocate when it is full.
(JavaScript has the same problem. Java, whose Strings are also immutable
is better because it has the StringBuffer class.)

It was reasonable to expect the cost of interpreter overhead and overly-general
data structures would be modest. Perhaps if Perl has received the same
resources as JavaScript or Java it would have been.

> Could we not get those benefits by writing in Go instead?  (Not that I'm
> proposing this).

All I am saying is: If you're looking into re-writing some code into C anyway,
why not allow yourself some of the benefits of C++?

I'm not saying C++ is the best language in the abstract. It does have the
virtues of being well-established, with an originator who is still active,
supported by an active standardization organization, with at least two Free
implementations, generating efficient code, and with mostly well-designed
and efficient libraries.

Also, it is mostly a superset of C, a language you are familiar with
and favorable to using.

> I have a small amount of experience in C++ with the Qt library
> (see https://github.com/GavinSmith0123/OpenBoard/commits/smart-import) and
> downsides I have found include long compilation times,

I suspect the long compliation times are because C++ files tend to include
many and large header files. Qt applicataion are probably more likely to
supprt from these. You could potentially have the same problem with C.

> long error messages in the case of templates,

That is a concern. It is one motivations for "concepts" - not for application
programmers, but for sophistcated library develpers to provide more
meaningful error messages.

However, no reason to use templates much, except perhaps some container
classes (such as hash tables) from the standard library

> Adding a function to a class forces recompilation of a large part of the
> program due to header files changing.

Recommended practice in C is for all non-local functions to be declared
in a header file.  So you're going to have the same problem.

> Editing C++ code is harder with a standard text editor and you are
> pushed to use IDEs to do things like updating header files and getting
> autocompletion.

I use plain Emacs. I'm not using the new "emacs as an IDE" packages that
are now available. It's hard for me to learn too many new tricks at a time.
Perhaps when all of this new-fangled stuff settles down I might try to learn it.

> I agree RAII is definitely a win although I doubt that there is such a
> thing as a "simple" subset of C++.  You list class inheritance as part of
> this although it is only occasionally useful, as far as I understand.

For texi2any I can imagine using different classes for different output formats
might make sense.  You might also have a hierarchy for texinfo commands.

> It's not necessary to have the possibility for polymorphism for every single
> function call or operator that occurs in a program.

Of course not. In C++ function are by default monomorphic (non-virtual).
In my domterm backend the keyword 'virtual' is not used at all.
--
        --Per Bothner
per@bothner.com   http://per.bothner.com/