In **my opinion**:
1) Shop functions should be C++ only, not returning or accepting
boost::python stuff. The python stuff (like converting std::vector to
python tuple/list or modifying input/output like [1]) is (should be)
the reason for py/_utils existence.
2) In the same way, there
Thanks for the 1st opinion, Jan.
To be clear, I do not want to propose any changes, it's just I'm writing
these days C++ functions with Python exposure, and I try to understand
the rationale (if any) behind this architecture before I reproduce it...
Jérôme
--
Chargé de Recherche /
Hi Jerome,
below please find my opinion. If the approach proposed by you works and
does not break existing code (or it is not easy to fix it), I would have
nothing against the refactoring.
What is the reason for having (for instance) Shop__getPorosity() in
> py/_utils.hpp/cpp and
Hi,
What is the reason for having (for instance) Shop__getPorosity() in
py/_utils.hpp/cpp and Shop::getPorosity() in pkg/dem/Shop.hpp /
Shop_01.cpp ?
I can see the latter has "scene" as an argument [1] in addition to
"volume" (contrary to the former [2]), but probably this could be
removed
4 matches
Mail list logo
