> And for programmers today who program by googling, googling does not > distinguish between good modern C++ solutions and crappy 15 year old > solutions that still work but should not be used today.
Sure, all jokes aside the difference between old and modern C++ is broadly speaking: 1. If you find yourself specifying the type, you are using old C++ -> always prefer auto, and duck typing 2. If you find yourself managing memory directly, you are using old C++ -> always prefer smart pointers 3. If you find yourself calling begin/end, acquire/release, do/undo function pairs you are using C -> prefer to wrap everything in RAII types. The ability to forgo types and write generic algorithms that only require *functionality* (and being able to assert this at compile-time) rather than a specific type name. Having an explicit memory ownership model that is enforced by construction via smart pointers. Making it impossible not to clean up after yourself via RAII. All “modern” C++ does is make the above more ergonomic and easier to do. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Jul 26, 2022, at 09:55, Barry Smith <bsm...@petsc.dev> wrote: > > > >> On Jul 26, 2022, at 9:43 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++ :) > > As joke, this is good, but reality is that C++ has 30 years of accumulated > junk, and I don't know of any automated way to prevent the use of that junk > from being used in PETSc, there is no C++ compiler flag --std-no-old-junk. > And for programmers today who program by googling, googling does not > distinguish between good modern C++ solutions and crappy 15 year old > solutions that still work but should not be used today. > >> >>> 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. > > PetscCall is because C does not have exceptions. Presumably, a modern C++ > PETSc would use exceptions for all error handling so would not need PetscCall > and friends at all? The stack on error would be handled in a modern C++ way. >> >> 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/ >>>> >>> >> >
