On Sat, Oct 05, 2024 at 02:52:55PM +0200, Patrice Dumas wrote: > > Commit a45bddf685edd (dated 2024-10-05, committed 2024-10-05) > > "Add C++ code to have an hashmap when Perl is not used" > > > > This adds C++ code to the project!! This is very concerning. We > > already have a lot of languages in the Texinfo project: TeX, Perl, C, > > even JavaScript. I have no desire to understand or maintain C++ code > > in Texinfo as well. It is also a lot for any new contributors in > > the future to get up to speed with (as things are, there may never be > > any such new contributors). Can we please find some alternative > > for whatever this C++ code is used for? > > There are three alternatives: > * Perl hashmap directly used from C > * linear search in C > * C++ hashmap used from C > > My understanding is that there is no other way than using C++ to have an > hash map in C, as was discussed in this thread: > https://lists.gnu.org/archive/html/bug-texinfo/2023-10/msg00074.html
We could also write our own implementation of a hash map or other data structure. It shouldn't be that difficult, we could look up algorithms online for how to write a hash map. > Note that this code is only used in a pure C implementation, in the > default case a Perl hashmap is directly used from C. What do you mean by a "pure C implementation"? Is this a program that converts Texinfo only using C, not using any Perl code as well? Is this why the Perl hashmap is not available, because it doesn't actually have a running instance of a Perl interpreter? > > You wrote to me in a private mail on 2024-05-25: > > > In the end I used the Perl HV to have a hash map, it works well (it > > > probably uses more memory), I propose not to use the C++ hashmap until > > > we completely remove Perl. > > This is still correct. But now, there is the demonstrator program fully > in C such that, even though we do not distribute that program (and I > think that we should not distribute it, it is for development only), we > are at that point that Perl is completly removed from that internal > program. To me, the main use of the demonstrator program is to compare > the timings with texi2any. If the linear search is used and not the C++ > hashmap, this is an 'unfair' treatment of the C program for this > purpose. How much slower would the linear search actually be? > To me, this C++ is not really in Texinfo code, it is more like an > external C library that happens to be in C++, but it is well separated. It doesn't appear this way to me. tp/Texinfo/XS/configure.ac checks for a C++ compiler with AC_PROG_CXX. So it is seems that present a C++ compiler is required to build Texinfo. There is also a C++ source file under tp/Texinfo/XS/convert/call_html_cxx_function.cpp in the same subdirectory as other source code files for the program. > If needed, I could try to make it part of contrib/ instead of being in > the main code. That would be an improvement. > > I have no interest in developing or supporting a public, stable API for > > hooking into texi2any internals. > > I do not think that it should be stable either. But we do have an API, > be it only because we need it for the interface of the converters > written in C. To me, it is similar to the Perl modules API, we do not > try to make it stable, but we have an API and it is better to treat it > as a regular interface ti have a clean code and modularity. OK, I misunderstood. The Perl modules do not have a stable, public API (which is what I understand by the term "API") because they are just part of the texi2any program, not supposed to be used independently. > > I have probably written emails about > > this before. It will tend to "freeze" texi2any implementation details > > and make further development more difficult. Users will probably not > > be able to achieve exactly the kind of output they want using the API > > and will come asking for help. (This already happens with the Perl > > customization API.) > > That's quite different, the Perl HTML customization API is for the > users, it is normal that they come asking for help. The C API is > equivalent with the perl modules API, not with the Perl HTML > customization API, and we have never had users coming for help for the > Perm modules API, and I believe that it is only used inside of GNU > Texinfo.
