> On Jul 26, 2022, at 10:49 AM, Boyce Griffith <[email protected]> wrote:
>
>
> clang-tidy can help with setting/enforcing C++ coding standards and avoiding
> some “old” C++ conventions / suggesting “modern” replacements.
Could we just run clang-tidy on PETSc 3 1000 times and end with PETSc future
:-)
>
>>>> 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 <[email protected]> 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 <[email protected]>
>>>>> 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 <[email protected]> wrote:
>>>>>>
>>>>>> On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <[email protected]> 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/
>>>>>
>>>>
>>>
>>
>
