> even more importantly we would need a huge amount of education as to what to > use and what not to use otherwise our hacking habits will fill the source > code with bad code.
As long as you never type “new” and “delete” then you are using modern C++ :) > Based on Jacob's contributions even "modern" C++ requires lots of macros. Not really. Most of the macros are in service of making C++-ish code work from C, and are used as a convenience. If I didn’t have to make the C++ callable from C, then we could remove many of the macros. Admittedly PetscCall() and friends would need to stay (unless we mandate C++23 https://en.cppreference.com/w/cpp/utility/basic_stacktrace) but now that they are uniform it would also not be difficult to factor them out again. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Jul 26, 2022, at 09:26, Barry Smith <bsm...@petsc.dev> wrote: > > > With C++ we would need good security guards on the MR who prevent use of > the "bad old C++" paradigms and only allow use of proper modern techniques; > even more importantly we would need a huge amount of education as to what to > use and what not to use otherwise our hacking habits will fill the source > code with bad code. > > Based on Jacob's contributions even "modern" C++ requires lots of macros. > Macros are horrible because it makes using automatic transformations on the > source code (that utilize the language structure and are not just regular > expression based) almost impossible. We've been doing some refactoring > recently (mostly Jacob with PetscCall and now I am adding more variants of > PetscCall) and we have to do them in a semi-automatic way with regex and > manual fixes which is painfully slow and prone to error; plus results in the > code not being updated everywhere so outdated parts remain hidden away for > future developers to trip over. I would really like to use a language > without macros, not one where macros are central and unavoidable. > > > >> On Jul 26, 2022, at 9:07 AM, Jacob Faibussowitsch <jacob....@gmail.com> >> wrote: >> >> IMO C++ is the pragmatic choice here. >> >> - Anyone with a C compiler is virtually guaranteed to have a C++ compiler >> these days, so no extra toolchain burden on users. >> - Our configure and build system already has all the infrastructure in place >> for C++ builds. >> - We already do half-C-half-C++ in the codebase, so users would actually >> never notice. >> - Modern C++ truly isn’t the unwieldy beast that C++03 was. Algorithms, the >> container library, and all the additional type safety no longer requires the >> insane template verbosity that it once did. >> - C++ has by far the widest user-base and adoption among all choices given, >> and given the heavy buy-in from corporate America we are guaranteed that C++ >> will see continued support for years (if not decades) to come. >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> >>> On Jul 26, 2022, at 08:30, Matthew Knepley <knep...@gmail.com> wrote: >>> >>> On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsm...@petsc.dev> wrote: >>> >>> A major problem with writing a completely new version of a large code >>> base is that one has to start with nothing and slowly build up to >>> everything, which can take years. Years in which you need to continue to >>> maintain the old version, people want to continue to add functionality to >>> the old version, and people want to continue to use the old version because >>> the new version doesn't have "the functionality the user needs" ready yet. >>> >>> Is there an approach where we can have a new PETSc API/language/paradigm >>> but start with a very thin layer on the current API so it just works from >>> day one? >>> • to this would seem to require if PETSc future is not in C, there has >>> to be a very, very easy way and low error-prone way to wrap PETSc current >>> to be called from the new language. For example, how petsc4py wraps seems >>> too manual and too error-prone. C++ can easily and low-error prone call C, >>> any other viable candidates? >>> This looked like the most promising thing about Zig. We could develop the >>> new modules alongside the existing C, and throw them away >>> if we decide it is not worth it. >>> >>> Matt >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which their >>> experiments lead. >>> -- Norbert Wiener >>> >>> https://www.cse.buffalo.edu/~knepley/ >> >
