> 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/
>>>
>>
>
