-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code generation with preprocessor metaprogramming #44
Comments
I'm against changing code for its own sake, even if the new code is
better. But in this case, the old code does not provide some needed
functionality. So I'm open to the idea; but I would want to see it well
tested before merging.
…-- Elizabeth
On Mon, Jul 2, 2018 at 9:09 AM, Sylwester Arabas ***@***.***> wrote:
Thank you!
I would vote for embracing it (i.e., simplifications and generalisations
using Boost preprocessor as exemplified in the above diffs)!
@citibeth <https://github.com/citibeth>, @pguio <https://github.com/pguio>,
@lutorm <https://github.com/lutorm>, Julian?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AB1cd7NxI7P0x9DhyXdRJbvNKeQ9UBlcks5uChuYgaJpZM4U_Pqy>
.
|
Re: "... which [dimension] amount I define by a macro" - I wonder if this could actually offer also an option to for users to reduce compilation time - assuming most of them do not use 11 dimensions for Blitz arrays - to be tested |
I’m glad you like it. I created a fork here on github, where I squashed the above diffs into a single commit. It has been tested a lot over the last few years within my quantum-simulation framework, C++QED, which uses |
@slayoo Dear Sylwester, do you think that the reduction of the amount of code can itself cut on the compilation time? Because otherwise the unused templates are not instantiated anyway, so it doesn’t do any harm for them to be there in the source code. |
@vukics this was more of a question than statement, thanks |
Without moving to C++11 (#9), a lot of repetitions in the blitz++ codebase could be omitted using preprocessor metaprogramming.
This would invoke dependence on one more boost library, but that’s no problem I guess?
I actually have to maintain a fork of blitz++ here because the maximal arity for the slicing operations is sometimes insufficient for my application. I used preprocessor metaprogramming to generate the necessary amount of slicing functions, which amount I define by a macro.
You can have a look at the solution in these relevant commits:
http://sourceforge.net/p/cppqed/blitz/ci/9b49b225eaf6c9f8f8cb9e039e51d7a2cb056a27
http://sourceforge.net/p/cppqed/blitz/ci/dd01d5816e6e6f56d9d0b299c5a3c999aff676b9
http://sourceforge.net/p/cppqed/blitz/ci/b28e85ab238e1d8bcf4ec4636ec965a9106b76cd
Any chance of such solutions being pulled into the default branch?
The text was updated successfully, but these errors were encountered: