> On Jul 26, 2022, at 10:51 AM, Barry Smith <[email protected]> wrote:
>
>
>
>> 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 :-)
Maybe it is a projection operator. I’ve never checked.
>>>>> 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/
>>>>>>
>>>>>
>>>>
>>>
>>
>
