[intrusive] New source-breaking version uploaded to SVN
Hi to all, I've uploaded to SVN a new version of Boost.Intrusive that uses the new option specification syntax discussed some time ago in this mailing list: using namespace boost::intrusive; class MyClass : public list_base_hook < void_pointer<offset_ptr<void> > , link_mode<auto_unlink> > { //... }; typedef list<MyClass, constant_time_size<false> > IntrusiveList; The new syntax is more verbose, but easier for common uses: class MyClass : unordered_set_base_hook<> { friend operator==(...); friend hash_value(...); }; //We don't need to specify default hash and equality functors typedef unordered_set<MyClass> MyHashSet; I've uploaded the new documentation here: http://igaztanaga.drivehq.com/intrusive Documentation is still lacking but I think it's fairly adapted to the new syntax. Apart from the new syntax, new features: -> Added stateful value traits. -> Fixed bug in 64 bit platforms (thanks Glenn!). -> Added support for custom bucket traits in unordered containers. -> Added option to use masks instead of modulo operations to determine the bucket number from the hash value (provided bucket length is always power of two). -> Changed all recursive functions from red-black tree algorithms with non-recursive ones (thanks Steven!). Interface change is a big change in the library, so I expect complaints from users. But I think the new syntax is much easier to use, specially as new options are added (unordered containers now receive upt o 7 options!). And the time to do breaking changes is before the library is officially released. Suggestions, improvements and comments are welcome ;-) Regards, Ion P.S.: If users prefer the old syntax, we can go back again to the old way. Just be polite ;-)
On 9/27/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
P.S.: If users prefer the old syntax, we can go back again to the old way. Just be polite ;-)
How does this affect compile time? Considering these things will probably only be typed once anyway for a typedef, and that most users will only care about a few common args, is an increase in compile time worth it? I'm straddling the line of calling this "overkill in the name of cleverness", but I will have to try it out and see how it runs. -- Cory Nelson
Cory Nelson wrote:
On 9/27/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
P.S.: If users prefer the old syntax, we can go back again to the old way. Just be polite ;-)
How does this affect compile time? Considering these things will probably only be typed once anyway for a typedef, and that most users will only care about a few common args, is an increase in compile time worth it?
That's something I expect users to judge. The new version also has some helper metafunctions that reduce compilation times and symbol length: http://igaztanaga.drivehq.com/intrusive/intrusive/obtaining_same_type_reduci...
I'm straddling the line of calling this "overkill in the name of cleverness", but I will have to try it out and see how it runs.
When the interface change was discussed there was no objection except my worries about compilation times/symbol length. I've spent a lot of time trying to minimize compilation times with the new approach but obviously, they are higher than before. I repeat: if users prefer the old syntax, I'm open to rescue the old syntax adding the features added in the last version. Even if I preferred the old way because of compilation times I appreciate the new syntax. Boost.Intrusive users will make the final choice, so I expect your comments and suggestions. Regards, Ion
On 9/27/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Cory Nelson wrote:
On 9/27/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
P.S.: If users prefer the old syntax, we can go back again to the old way. Just be polite ;-)
How does this affect compile time? Considering these things will probably only be typed once anyway for a typedef, and that most users will only care about a few common args, is an increase in compile time worth it?
That's something I expect users to judge. The new version also has some helper metafunctions that reduce compilation times and symbol length:
http://igaztanaga.drivehq.com/intrusive/intrusive/obtaining_same_type_reduci...
I'm straddling the line of calling this "overkill in the name of cleverness", but I will have to try it out and see how it runs.
When the interface change was discussed there was no objection except my worries about compilation times/symbol length. I've spent a lot of time trying to minimize compilation times with the new approach but obviously, they are higher than before. I repeat: if users prefer the old syntax, I'm open to rescue the old syntax adding the features added in the last version.
Even if I preferred the old way because of compilation times I appreciate the new syntax. Boost.Intrusive users will make the final choice, so I expect your comments and suggestions.
After using it now, I can say I could live with the new, but much prefer the old. Here are some thoughts: Compile time increases with VC++ have proven trivial in the grand scheme of things, even when specifying several options. The common use cases are still simple. In spots where "using namespace boost::intrusive" is impossible or inappropriate, you are in for a lot of typing if you want to specify some options. Typedefs lower the amount of annoyance, but it's still something you would not have to worry about with traditional syntax. You get extra verbosity, but I think a better place for this would be in comments where we can use much more descriptive natural language, won't affect compile time, and won't have to redundantly specify the namespace so much. The make_* stuff is usable but feels like what it is: a hack to work with random order options. -- Cory Nelson
ANDG Cory Nelson <phrosty <at> gmail.com> writes:
The common use cases are still simple.
In spots where "using namespace boost::intrusive" is impossible or inappropriate, you are in for a lot of typing if you want to specify some options. Typedefs lower the amount of annoyance, but it's still something you would not have to worry about with traditional syntax.
Use namespace aliases In Christ, Steven Watanabe
participants (3)
-
Cory Nelson -
Ion Gaztañaga -
Steven Watanabe