Return to Answer

I would consider the following alternatives, in that order:

1. Start with the DRY variant, even it is less efficient. In most real-world cases, this won't matter. If a benchmark tells you here is your bottleneck, go to option 2.

2. Give the get function a parameter where it is told whether one wants the intermediate values back or not. The parameter could be, for example, a boolean flag or a pointer to the output structure (here Stack) - when that pointer is NULL, no intermediate values will be returned.

   For this, I would keep the new get variant internal to the module (for example, call it get_internal), and provide two new public entries, like get and get_all. get could call get_internal(...,NULL) and get_all could call get_internal(...,&stack). So you don't have to leak the new parameter into the public API.

   In the unlikely case testing the extra parameter is still the bottleneck (and you proofed this by profiling), goto option 3:

3. Live with the duplication, because a specific implementation is really so much faster that it is worth to ignore the DRY principle. This option is something I would only recommend after a thorough benchmark which proofs the two former variants are both too slow to fulfill your performance requirements, and #3 really solves it.

   In case the duplication becomes really horrible, and you think #1 and #2 are definitely not fast enough, as a last resort, there is option 4:

4. Implement the get_internal function not with a runtime parameter, but make use of compile time parameters / macros, for providing actually two variants of the function (from one source code). In C++, one could make use of template meta programming to make a relatively clean implementation of this. In C, this can be sometimes necessary, but there is a certain risk to end up in some ugly macro hack where it is debatable if that's better or worse than sacrifycing DRY. So if you consider to go this route, better think twice if it is really worth the hassle.

I would consider the following alternatives, in that order:

1. Start with the DRY variant, even it is less efficient. In most real-world cases, this won't matter. If a benchmark tells you here is your bottleneck, go to option 2.

2. Give the get function a parameter where it is told whether one wants the intermediate values back or not. The parameter could be, for example, a boolean flag or a pointer to the output structure (here Stack) - when that pointer is NULL, no intermediate values will be returned.

   For this, I would keep the new get variant internal to the module (for example, call it get_internal), and provide two new public entries, like get and get_all. get could call get_internal(...,NULL) and get_all could call get_internal(...,&stack). So you don't have to leak the new parameter into the public API.

   In the unlikely case testing the extra parameter is still the bottleneck (and you proofed this by profiling), goto option 3:

3. Live with the duplication, because a specific implementation is really so much faster that it is worth to ignore the DRY principle. This option is something I would only recommend after a thorough benchmark which proves the two former variants are both too slow to fulfill your performance requirements, and #3 really solves it.

   In case the duplication becomes really horrible, and you think #1 and #2 are definitely not fast enough, as a last resort, there is option 4:

4. Implement the get_internal function not with a runtime parameter, but make use of compile time parameters / macros, for providing actually two variants of the function (from one source code). In C++, one could make use of template meta programming to make a relatively clean implementation of this. In C, this can be sometimes necessary, but there is a certain risk to end up in some ugly macro hack where it is debatable if that's better or worse than sacrifycing DRY. So if you consider to go this route, better think twice if it is really worth the hassle.

I would consider the following alternatives, in that order:

1. Start with the DRY variant, even it is less efficient. In most real-world cases, this won't matter. If a benchmark tells you here is your bottleneck, go to option 2.

2. Give the get function a parameter where it is told whether one wants the intermediate values back or not. The parameter could be, for example, a boolean flag or a pointer to the output structure (here Stack) - when that pointer is NULL, no intermediate values will be returned.

   For this, I would keep the new get variant internal to the module (for example, call it get_internal), and provide two new public entries, like get and get_all. get could call get_internal(...,NULL) and get_all could call get_internal(...,&stack). So you don't have to leak the new parameter into the public API.

   In the unlikely case testing the extra parameter is still the bottleneck (and you proofed this by profiling), goto option 3:

3. Live with the duplication, because a specific implementation is really so much faster that it is worth to ignore the DRY principle. This option is something I would only recommend after a thorough benchmark which proofs the two former variants are both too slow to fulfill your performance requirements, and #3 really solves it.

   In case the duplication becomes really horrible, and you think #1 and #2 are definitely not fast enough, as a last resort, there is option 4:

4. Implement the get_internal function not with a runtime parameter, but make use of compile time parameters / macros, for providing actually two variants of the function (from one source code). In C++, one could make use of template meta programming to make a relatively clean implementation of this. In C, this can easily end up in some ugly macro hack where it is debatable if that's better or worse than sacrifycing DRY, so if you consider to go this route, better think twice if it is really worth the hassle.

I would consider the following alternatives, in that order:

1. Start with the DRY variant, even it is less efficient. In most real-world cases, this won't matter. If a benchmark tells you here is your bottleneck, go to option 2.

2. Give the get function a parameter where it is told whether one wants the intermediate values back or not. The parameter could be, for example, a boolean flag or a pointer to the output structure (here Stack) - when that pointer is NULL, no intermediate values will be returned.

   For this, I would keep the new get variant internal to the module (for example, call it get_internal), and provide two new public entries, like get and get_all. get could call get_internal(...,NULL) and get_all could call get_internal(...,&stack). So you don't have to leak the new parameter into the public API.

   In the unlikely case testing the extra parameter is still the bottleneck (and you proofed this by profiling), goto option 3:

3. Live with the duplication, because a specific implementation is really so much faster that it is worth to ignore the DRY principle. This option is something I would only recommend after a thorough benchmark which proofs the two former variants are both too slow to fulfill your performance requirements, and #3 really solves it.

   In case the duplication becomes really horrible, and you think #1 and #2 are definitely not fast enough, as a last resort, there is option 4:

4. Implement the get_internal function not with a runtime parameter, but make use of compile time parameters / macros, for providing actually two variants of the function (from one source code). In C++, one could make use of template meta programming to make a relatively clean implementation of this. In C, this can be sometimes necessary, but there is a certain risk to end up in some ugly macro hack where it is debatable if that's better or worse than sacrifycing DRY. So if you consider to go this route, better think twice if it is really worth the hassle.

I would consider the following alternatives, in that order:

1. Start with the DRY variant, even it is less efficient. In most real-world cases, this won't matter. If a benchmark tells you here is your bottleneck, go to option 2.

2. Give the get function a parameter where it is told whether one wants the intermediate values back or not. The parameter could be, for example, a boolean flag or a pointer to the output structure (here Stack) - when that pointer is NULL, no intermediate values will be returned.

   For this, I would keep the new get variant internal to the module (for example, call it get_internal), and provide two new public entries, like get and get_all. get could call get_internal(...,NULL) and get_all could call get_internal(...,&stack). So you don't have to leak the new parameter into the public API.

   In the unlikely case testing the extra parameter is still the bottleneck (and you proofed this by profiling), goto option 3:

3. Live with the duplication, because a specific implementation is really so much faster that it is worth to ignore the DRY principle. This option is something I would only recommend after a thorough benchmark which proofs the two former variants are both too slow to fulfill your performance requirements, and this one solves it.

I would consider the following alternatives, in that order:

1. Start with the DRY variant, even it is less efficient. In most real-world cases, this won't matter. If a benchmark tells you here is your bottleneck, go to option 2.

2. Give the get function a parameter where it is told whether one wants the intermediate values back or not. The parameter could be, for example, a boolean flag or a pointer to the output structure (here Stack) - when that pointer is NULL, no intermediate values will be returned.

   For this, I would keep the new get variant internal to the module (for example, call it get_internal), and provide two new public entries, like get and get_all. get could call get_internal(...,NULL) and get_all could call get_internal(...,&stack). So you don't have to leak the new parameter into the public API.

   In the unlikely case testing the extra parameter is still the bottleneck (and you proofed this by profiling), goto option 3:

3. Live with the duplication, because a specific implementation is really so much faster that it is worth to ignore the DRY principle. This option is something I would only recommend after a thorough benchmark which proofs the two former variants are both too slow to fulfill your performance requirements, and #3 really solves it.

   In case the duplication becomes really horrible, and you think #1 and #2 are definitely not fast enough, as a last resort, there is option 4:

4. Implement the get_internal function not with a runtime parameter, but make use of compile time parameters / macros, for providing actually two variants of the function (from one source code). In C++, one could make use of template meta programming to make a relatively clean implementation of this. In C, this can easily end up in some ugly macro hack where it is debatable if that's better or worse than sacrifycing DRY, so if you consider to go this route, better think twice if it is really worth the hassle.