Le 9 oct. 2014 à 22:20, Joaquin M Lopez Munoz
This is what's hapenning:
1. make(v) creates a *temporary* flyweight(v), which contains a make_num struct containing a std::shared_ptr
.
Ah, yes, of course. Thanks. This is fixed now.
Why do you want to have a factory per node type?
To be able to try it and to bench it. I'd like to be sure about the choice to make wrt the overhaul of my ASTs, and the options I have so far seem to be: a. a single factory based on Flyweight, and use derived_poly_flyweight b. one factory made by hand on top of map or unordered_map c. likewise, but with Flyweight and key_value
Hash containers' performance is basically independent of the number of elements being contained, so you won't get any significant speedup by separating types --what's more, you can even get a performance reduction due to CPU cache misses, since having more hashed containers around places more bucket arrays in the program's working memory.
Well, this is not so clear to me, as the expressions I store have often a strong regularity, with many elements of the same kind in a row. Besides, I appreciate that I can get rid of one level of indirection, as the factories now store genuine objects, not pointers to them. And I expect this to have quite a positive impact on the performances. b features this, and has the advantage that there are fewer types to deal with in the library: it's just shared_ptr and that's something people know. But actually b does not work properly yet, and I probably have to deal with ref-counting myself, because the version which is in the store should not count. There are contributors and users of this library, so I am also concerned with the learning curve for people who would want to use it. Yet speed is a primary concern. Since eventually we will certainly go parallel, I also appreciate Flyweight's safety. So really, I'd like to have toy implementations of a, b, and c, and them decide what to do (well, discuss with the other members and see what conclusion emerges). I feel that Boost.Flyweight has everything I need: it keeps the right ref counter, can support key-value map, it is safe, well documented etc. Yet I have to find a means to get polymorphism back in business.