serizba
cppflow2: declare `inline` for header only implementation
As #73 suggested, non-template function definition in header needs to be declared as inline to avoid ODR violation. This requires changes in both the auto-generated header and the manually written headers.
This may not be important if we are going to separate the implementation into cpp files, but we need to address them if we want to keep the library header only.
This has caused me issues as well. For the time being, I just manually added the inline keyword to all the necessary methods in my local copy, but this should probably be implemented.
Yes, it's true, we should do something about.
I don't know if we should continue with a header only structure or move the implementations into a cpp files. At the beginning I started the code as a header-only library as I though I would require lot of templated functions, but now is not that the case.
I don't know, perhaps we should switch...
I am working on a large project with the constraint of using c ++ 14. Most companies have old Ubuntu 16 in production that are not natively compatible with c ++ 17. Inline variables are implemented from c ++ 17, I chose to switch to the cpp implementation with a static lib compilation to avoid adding cpp to the project files.
@serizba There are too many people complaining this. Maybe I will add the missing inline declaration to temporarily solve this for now. It seems it is the easiest way to do.
Yes, we have to address this.
But I am not sure on whether to stick with the header-only implementation or switch definitions to cpp files.
I am not sure either.... In my opinion, it is more like a lib design choice. Both have their own pros and cons. The PR #81 chose to keep header only structure simply because it took the minimum effort to solve this problem. In other words, it is not recommending header-only is better.
I think that for the moment I will stick with the header-only implementation and I will accept PR #81.
I already made the effort to convert from header to .Cpp/. H implementation. Switching to inline implementation will not break c++ 14 compatibility?
@khaled-besrour To be honest, I am against moving back to C++ 14 (sorry) because we are considering conditionally importing C++20 features (std::span).
As the proverb say:
There is nothing more permanent than a temporary solution.