> engage in incremental development. Incremental development that goes the other way though (unless I have misunderstood) i.e. you have base C-code that is called from C++. If you need C++ from C, then you need macros to generate the stubs for each instantiated template, but if you need C from C++ then you can simply overload (no need for macros).
Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Jul 26, 2022, at 09:51, Matthew Knepley <knep...@gmail.com> wrote: > > On Tue, Jul 26, 2022 at 8:44 AM Jacob Faibussowitsch <jacob....@gmail.com> > wrote: > > 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. > > But the start of this thread made clear that this is _exactly_ what we want > to do, engage in incremental development. > > Matt > > 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/ > >> > > > > > > -- > 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/
