Lines Matching refs:be
75 2. `PetscCount` is `ptrdiff_t`, (on 64-bit systems it is 64-bits) and should be used for array size…
76 and indices that may become large. `PetscIntCast()` should always be used when converting
79 when these arrays get too large then `--with-64-bit-indices` must be used to
83 It should **not** be used for the number of
84 entries in an array, or to index into an array, that should be `PetscCount`, or `PetscInt`.
85 Though `size_t` is unsigned and hence can have values larger than those that can be stored
86 …in a `PetscCount` those sizes will never be reached in practice so it is ok to cast with `(PetscCo…
111 sizeof(MPI_Count) may be strictly greater than sizeof(PetscInt64)
121 … in the entire repository with `make clangformat`. All merge requests must be properly formatted; …
123 …ang-format` there are still many decisions about code formatting that must be constantly made. A s…
133 02. All local variables of a particular type (for example, `PetscInt`) should be listed
134 on the same line if possible; otherwise, they should be listed on adjacent lines. Note
135 …that pointers of different arity (levels of indirection) are considered to be different types. `cl…
148 03. Local variables should be initialized in their declaration when possible
190 `PetscCall()` macro. This should be wrapped around the function in question.
213 09. Single operation `if` and `else` commands should not be wrapped in braces. They should be done …
229 11. Use classic block comments (`/* There must be a space before the first word in the comment and …
238 15. All variables must be declared at the beginning of the code block (C90
253 be declared inside the loop initializer:
292 17. The use of `// clang-format off` is allowed in the source code but should only be used when nec…
293 be used when trailing // to split lines works.
301 …nk` should be used exclusively for the results of `MPI_Comm_size()` and `MPI_Comm_rank()` and othe…
312 should be labeled as `const` arguments.
314 03. Scalar values passed to functions should *never* be labeled as
318 a pointer to some data should be prototyped as `void *`.
330 08. Header guard macros should be done using `#pragma once`. This must be the very first
331 non-comment line of the file. There must be no leading or trailing empty (non-comment)
381 10. Variadic macros may be used in PETSc, but must work with MSVC v1900+ (Visual Studio
394 should be able to read any part of the macroblock and find or deduce the
452 PETSc, whereas the latter needs to be compiled with and without debugging
469 09. Make error messages short but informative. The user should be able to reasonably
472 10. Except in code that may be called before PETSc is fully initialized,
478 should not be used in PETSc without appropriate `configure`
479 checks and `#if PetscDefined()` checks. Code should also be provided
500 14. Library symbols meant to be directly usable by the user should be declared
501 …ctive public header file. Symbols intended for internal use should instead be declared `PETSC_INTE…
503 be declared `static`. PETSc can be configured to build a separate shared
505 implementations of these classes can be included as separate shared libraries; thus,
506 otherwise private symbols may need to be marked `PETSC_SINGLE_LIBRARY_INTERN`. For
512 headers (`include/petsc*.h`) should be marked `PETSC_EXTERN`;
514 `PETSC_SINGLE_LIBRARY_INTERN` as it may be used across library boundaries, but is
515 not intended to be visible to users;
518 `PETSC_DEPRECATED_XXX()` should be used in the relevant header file
525 The function or type’s manual page should be updated (see {ref}`manual_page_format`).
540 Note that after compiler preprocessing, the enum above would be transformed into something like
550 `PetscOptionsDeprecated()` should be used for at least one major
560 such as `PetscPrintf`, must be cast to `double`, for example,
570 for Sowing and the formatting may be found at
576 a formatted comment of a function that will be used for documentation and a Fortran interface.
578 …a formatted comment of a function that will be used only for documentation, not to generate a Fort…
617 Sowing. All entries below should be separated by blank lines. Except
630 - `Not Collective` if the function need not be called on multiple (or possibly all) MPI
637 MPI communicator should be noted here.
648 07. If any input or output parameters are function pointers, they should be documented in the style
661 should be listed before the various `Note(s):` sections.
665 whether returned pointers/objects need to be freed/destroyed by the
666 user or not, this information should be mentioned here.
675 13. (If applicable) references should be indicated inline with \{cite}\`Bibtex-key\` where
681 comment. There should be no blank line after the `.seealso:` items.
683 …r in a manual page (except the one in the header at the top) should end with a `()` and be enclosed
684 …in single back tick marks. All PETSc enum types and macros etc, should also be enclosed in single …
699 1. Proper nouns, including Unix, Linux, X Windows, and Microsoft Windows, should be fully written a…
701 2. Company names and product names should be capitalized.
702 …re traditionally all capitalized, for example, MATLAB, NVIDIA, and CUDA, should be all capitalized.
704 5. Unix should not be all capitalized.
705 6. Microsoft Windows should always be written out with two words. That is, it should not be shorten…
706 7. CMake should be capitalized as shown.