Skip to content

Commit

Permalink
Update doc links for latest IMP
Browse files Browse the repository at this point in the history
  • Loading branch information
benmwebb committed Jun 13, 2024
1 parent 2ee977d commit f947c4d
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions doc/valgrind.ipynb
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@
"source": [
"# Build procedure<a id=\"build\"></a>\n",
"\n",
"To build the custom module, either drop the entire module into IMP's `modules` directory and then build IMP from source code [in the usual way](https://integrativemodeling.org/2.20.2/doc/manual/installation.html#installation_compilation), or build the module [out of tree](https://integrativemodeling.org/2.20.2/doc/manual/outoftree.html) pointing CMake to an existing IMP installation. In order for Valgrind to be maximally useful, build the module with extra debugging information available by passing `-DCMAKE_CXX_FLAGS=\"-g\"` to CMake. The module should build without errors (or even warnings) with gcc."
"To build the custom module, either drop the entire module into IMP's `modules` directory and then build IMP from source code [in the usual way](https://integrativemodeling.org/2.21.0/doc/manual/installation.html#installation_compilation), or build the module [out of tree](https://integrativemodeling.org/2.21.0/doc/manual/outoftree.html) pointing CMake to an existing IMP installation. In order for Valgrind to be maximally useful, build the module with extra debugging information available by passing `-DCMAKE_CXX_FLAGS=\"-g\"` to CMake. The module should build without errors (or even warnings) with gcc."
]
},
{
Expand Down Expand Up @@ -145,7 +145,7 @@
" - In more complex programs with multiple code paths it can be tricky to make sure that every `new` is paired with a `delete` and that we never try to free the same memory more than once.\n",
" \n",
"\n",
"In this case where the object is small it would be better to avoid dynamic memory allocation entirely and just create the `ScoreCalculator` object as an automatic variable (on the stack) as `ScoreCalculator calc(d, k_);` For a larger object, derive from the [IMP::Object](https://integrativemodeling.org/2.20.2/doc/ref/classIMP_1_1Object.html) class and use a [smart pointer](https://en.wikipedia.org/wiki/Smart_pointer) to make sure it gets cleaned up automatically (replacing `new` with `IMP_NEW` and using `IMP::Pointer` rather than raw C++ pointers).\n",
"In this case where the object is small it would be better to avoid dynamic memory allocation entirely and just create the `ScoreCalculator` object as an automatic variable (on the stack) as `ScoreCalculator calc(d, k_);` For a larger object, derive from the [IMP::Object](https://integrativemodeling.org/2.21.0/doc/ref/classIMP_1_1Object.html) class and use a [smart pointer](https://en.wikipedia.org/wiki/Smart_pointer) to make sure it gets cleaned up automatically (replacing `new` with `IMP_NEW` and using `IMP::Pointer` rather than raw C++ pointers).\n",
"\n",
"(Valgrind also reports some small memory leaks from IMP's SWIG interface. These aren't worth worrying about, since this is not our code, and they should be one-time allocations, which get cleaned up at the end of the program anyway.)\n"
]
Expand Down

0 comments on commit f947c4d

Please sign in to comment.