- Boost - lists.boost.org

Re: [boost] Review of Intrusive library begins today March 12
by Ion Gaztañaga 23 Mar '07

23 Mar '07

Hi Pavel, Nice to see you've found time to the the review. I will reply the comments that I'll consider most important: Pavel Vozenilek wrote: > * An vector-like pseudo-intrusive container may be added. > It is superfluous but people may like it more than lists. Well, a vector is not even pseudo-intrusive, because it has no nodes. std::vector<> + allocator is not sufficient in your opinion? > (Is a map like intrusive container possible, btw?) I think a map-like intrusive structure is not very useful. A iset with a value type that has std::pair interface is enough, the advanced search functions can be used to compare the key part with the value type. > * More examples, e.g. one example per every combination of > hooks and containers, just to have something to copy, paste and play. "Every combination" might be too much ;-) but when presenting each container, I might add example using different hooks. > ================================================================ > One existing library that implement intrusive containers is Data Object > Library > (http://www.codefarms.com/dol.htm, also http://www.codefarms.com/ptl.htm) > > > This library uses external, preprocessor like, tool to generate > code that handles lifetime management of the data. > It meansd that you create an object, add into into how many > containers you want and when it is removed from the last > container then it gets automagically deleted. > > > Author of the library claimed development time speedup 10x > comparing to classical manual lifetime management. > > jjLib (http://sourceforge.net/projects/jjlib/) > is based on the same pronciples and also uses external > code generator. I will look these for ideas and new features. > What I imagine as potentially possible is for the > Intrusive Container library (or its complement) > to completely manage lifetime of inserted objects: > > * when an object is removed from the last container > it gets automatically deleted. This would need an embedded reference counted hook. but these reference count should be shared between all the hooks of a value type (including hoooks from base classes). Not an easy task to do in standard C++, I guess ;-), but I will put it in my investigation list. > ================================================================ > Naming conventions: > > * I would personally prefere names like boost::intrusive_slist. > The ilist is too easy to overlook and this type of naming is > used way too often to cause confusion. Ok. People consider boost::intrusive::slist good enough, but I have no problem with the names. > * The code snippets should not use generic names as Vector or List > for the same reason. Ok. > * ilist_auto_base_hook etc.: it is not really clear whether the > class is intended to be base (it would end with _base). It's difficult to find a meaningful short name. I think list_base_hook is good enough, but suggestions are welcome. > Perhaps auto_removing_i[ntrusive_]list_base. The word "hook" > looks as unnecessary. The member hook may look like: > auto_removing_i[ntrusive_]list_support. Others have proposed using a single class using template parameters to specify the linking policy (safe, normal, auto-unlink). > 1. overview.html: the sentence > > "On the other hand, an intrusive container does not store > copies of passed objects, but it stores the objects themselves." > > may be better w/o using work store: > > "On the other hand, an intrusive container does not insert > copies of passed objects, but it references the objects themselves, > without copying their data." > > or so. Your phrase is not convinging for me, but I don't find mine good enough. > "If you want to share an object between two containers, you either > have to store multiple copies of those objects or you need to > use containers of pointers: std::list<Object*>." > > append "... or of smart pointers" just to remind this. Ok. > ------------- > typo: Boost.Intrusivecontainer - missing space Ok. > -------------- > "In intrusive containers you don't store a copy of an object, > but rather the original object itself." > > may be better reworded to avoid "store" which usually implies copying. Ok, but which other word would you use? > ________________________________________________________________ > 2. concepts.html: > > Evry concept here may contain link to a small but complete example. > > If is the second page in documentation and it may be bit > too scaring for a newbie to get overloaded with abstract > concepts w/o seeing what it could be good for. I will try to link concepts. Others have proposed moving he full concepts page to the end of the documentation and start with an small summay. > The bullet item starting with "Node Traits" is a bit hard to parse: > > * the term basic operations may be explained (or at least > differenciated from NodeAlgorithms at this point) > * "defines the interface" may be better "expects interface" > > typo " to its own class" -> "to his own class" Ok. > "ValueTraits will contain the information to convert user classes > in nodes compatible with Node Algorithms." > > I am missing what are the user classes converted into > (that's that way I parsed it). Ok. I will try to improve this. > I do not like the term "Pseudo-Intrusive Container" > * it suggest something less worth that the "real container" > * it gives impression that the essence of intrusiveness > is missing here, which it is not, AFAICS > > Perhaps "Intrusive Container with auxiliary allocated memory" > looks clumsy but it exactly says what it is and nothing more. I would prefer something shorter ;-) > In concepts summary: the sentence > > "Node Algorithm: A class containing typedefs and static functions > that manage a group of nodes." > > - the word "manage" is used for the first tima and may > mean quite a many things. Something like "...that define basic operations that can be applied to a groups of nodes"? > The term "Node" if not defined and assumed implicitly > (or from one prior code snippet). ...and this one it's quite difficult to define, I'm afraid. > ------------- > Possibly the names of the concepts may reflect > which concetps are already implemented by the > library and which always need to be reimplemented > by the user. All these concepts are implemented by the library, even though some are customizable by the user. > Auto-unlink hooks are mentioned here for the first time > but ony in one sencence, As this may be one of the most > useful features there ay be a link and/or example > so the reader would be able to test it immediatelly. Ok, a link to the auto-unlink hooks page would be enough. > ________________________________________________________________ > 4. usage.html: > > Possibly this page may contain a link > to complete examples of all possible combinations, e.g.: > > * node with base hook > * node with several base hooks > * node with member hook > * node with several member hooks Don't you think this is a bit too much? Do you think an example using both (base and member) is too confusing? > It may be mentioned that tag does not need to be fully specified. Ok. > ------------- > the code snippet with > typedef boost::intrusive::ilist_base_hook<Foo>::value_traits<Foo> > FooValueTraits; > > > contradicts the complete example bellow with: > > typedef ilist< ilist_base_hook<my_tag>::value_traits<MyClass> > BaseList; > > (in what is used as the template parameter of value_traits). Well, MyClass is a concrete class of the example, so I thought it was not confusing, I could just write MyClass in both examples, if that's less confusing. > "With these features, without any external reference > the user can know if the object has been inserted in > a container." > > - this should mention the API call to find out this information. Ok. > --------------- > The safe mode (probably) applies to single hook, not for > situations with two or more hooks. No, the safe mode is applied for every hook. If you try to insert an object in a container and it's already inserted in another container that uses the same hook, the code will assert. > The items: > * the programmer needs to efficiently track the construction and destruction > of objects > * exception safety, especially the no-throw guarantee, is needed > > may need bit more context. > > The item: > * additional memory management should be avoided > > may talk rather about the allocation. I'll try to elaborate a bit more. > //This is a container of abstract values: you can't do this with std::list. > typedef boost::intrusive::ilist< Window::value_traits<Window> > win_list; > > "abstract value" is what? Ok. "Abstract class" is maybe more correct? > ________________________________________________________________ > 6. auto_unlink_hooks.html: > > "non-constant time containers" - should have backlink > to information what it is. Ok. > ---------------- > "If several threads are using the same container, > removing the object is thread-unsafe." > > I guess that is true for removing an item from > container explicitly. I will improve it. The difference is that removing explicitly can be executed with a locked mutex, whereas the destructor is not explicitly called, will be automatically executed and the user might forget this operation. > ---------------- > > "Container contents change silently without touching the > container directly. This can lead to surprising effects." > > touching => referencing > This can lead ... => Touching is not referencing. Touching should say "modifying" > The bool used for SafeMode template parameter may be replaced > by an enum and symbolic name. Ok. > ilist_auto_base_hook<>::linked() > > may be is_linked() or is_in_container(). is_linked() sounds good. No problem to change it. > --------------- > Possible change in API: the second and third template parameters > may be merged into one, like: > > template<class ValueTraits, class SizeType = std::size_t> > class islist; > > and for no constant size() used as > > ilist<a_tag, boost::size_not_kept> I've already explained that I consider these properties orthogonal. You might not have a constant-time size but still need a non trivial std::size_t to give support for allocator based non-intrusive containers. > Explanation why the islist is circular and > what impact it has on semantics is missing. Others prefer to remove this reference and not say how it's implemented. I think this should be the case with list/slist/set-containers that can be implemented differently. If more containers are added, like irbtree/avl_tree or similar, this should be explained. > It would be interesting to hear whether > the "two-way pointers" > (e.g. http://www.semantics.org/code.html#flist) > could be used together with Boost.Intrusive Containers. I will investigate it. > ________________________________________________________________ > 9. iset_imultiset.html: > > "Boost.Intrusive also offers associative containers > that can be very useful when creating more complex > associative containers,..." > > - this is like saying a class may be used to built > more complex classes, i.e. redundant (unless I am missing > something). Ok. I´ll remove it. > OT question: could a intrusive container > with the data be ROMable? This may be mentioned > somewhere. I don't think so, because an intrusive container must modify the objects. > ________________________________________________________________ > 10. iunordered_set_iunordered_multiset.html: > > memory allocator may be added as template parameter. > If someone has really critical need for speed he may employ > a zone allocator. I prefer maintaining memory allocator out of Intrusive. I think this is the correct approach to maintain, even with pseudo-intrusive containers. > ________________________________________________________________ > 11. advanced_lookups_insertions.html: > > "advanced lookup" may be named "matching by partial key", > "advanced insertions" could be "optimized insertion". > > The lookup by partial key is employed by at least one > other library, if found it may be referenced. Apart from partial keys other types comparable with the value type can be used, so I don't like this term. > ________________________________________________________________ > 12. erasing_and_destroying.html: > [snip] > Possible problems with the approach here: > > * it is not possible to enforce that the objects > destroyed were dynamically allocated. > > * it is dangerous when object is part of more than > one intrusive container. > > * the names remove_and_destroy, erase_and_destroy > and clear_and_destroy are not very helpful. Some have proposed "dispose". I think this feature is really useful to easily build non-intrusive containers above intrusive containers. > ________________________________________________________________ > 13. clone_from.html: > [snip] > I noticed the documentation does not mention > copyability and assignability of the data handled > by intrusive containers. Pehaps the intro should > inform what is possible, what is recommended > and what dangers there are. The data handled by intrusive containers have no restrictions. It can be non-copyable and non-moveable, as it's explained in the documentation. > One needs to remember that the cloned container > needs to be destroyed explicitly and manually. > It feels rather dangerous. Just like the container from you cloned ;-) That's how intrusive containers work. Your clone function could have just allocate a vector of objects and return a reference instead of calling new. > class X { ... }; > > X x; > > ilist<X> c1; > ilist<X> c2; > c1.push_back(x); > > c1.clone_from(c1, ...); // will work c1 first clears the target container, so there is nothing to clone. > X x1; > X x2; > > ilist<X> c3; > ilist<X> c4; > c3.push_back(x1); > c4.push_back(x2); > > // will this crash? > // (the destroyed will try to delete the local x1) > c3.clone_from(c4, ...); The cloner will not try to delte the local x1, it will just call your destroyer function. Obviously, if you are using local objects this will crash, but with intrusive containers the programmer has the responsibility of memory issues. > ________________________________________________________________ > 14. using_smart_pointers.html > > offset pointer should not be called smart pointer. Why not? Smart pointers don't need to be related with lifetime management issues, as I understand the term. How would you call offset_ptr, a "pointer class"? > Boost.Smart Pointers is permitted here or not? No. > The docs may say why Boost.Smart Pointers are > not useful here. The docs already state that the smart pointers need to have the same ownership semantics as raw pointers. But i will explicitly say the Boost.SmartPointer classes are not compatible. > ________________________________________________________________ > 15. obtaining_iterators_from_values.html > [snip] > ------------ > > The docs may say what is this feature good for > (traversal, yes, but bit complicated as one needs > to keep the first obtained iterator). An iterator is the key to access to STL algorithms. If you have the value, you have access to STL algorithms. > Something as ability to get the end() and begin(), > that would be a killer feature. I'm afraid this will be difficult. > "local iterators" - a term I never saw before. > Without knowing what it is I do not get > half of the content here. It's in the hash table proposal for C++0x. > ----------- > > Now I understand that the node algorithms + traits > are like building blocks of the library (or are they > completely separate?). These are building blocks, but they can be used for other tasks where containers are not suitable. > > Custom ValueTraits example: > > "...we only need an extra pointer..." > > w/o the "extra". Ok. > Invalid comment in example code (on the bottom of this section): > //Now test both lists Ok. > ------------ > ValueTraits::value_type vs. NodeTraits::node > > - could be named "reusing primitive intrusive > operations for different values" "Reusing node algorithms for different values" might be better. > Boost.Intrusive in space constrained environments > > - here may be a table listing (again) the overhead > or calculation of the overhead for > list/slist/... node and of list/slist/... container. I will add this as a separate chapter. > "For example, the programmer can use Boost.Intrusive to manage > old data structures whose definition can't be changed." > > -> ...can customize parts of Boost.Intrusive ... Ok. > > ________________________________________________________________ > 19. acknowledgments.html: > > Joaquin M. Lopez Munoz - some diacritics is missing, doesn't? Yes. I still don't know how to insert them in Quickbook, maybe a UTF editor is needed to achieve this. In the header HTML style scape sequences can be used, but not in the documentation body. Don't worry Joaquín, I'll fix that ;-) > why is ilist(const ilist &); > listed in public interface if it is not implemented? > Dtto operator=(). Boostbook/Doxygen error. Recently fixed in CVS thanks to Eric Niebler. > void push_back(value_type &) ; > > - why non-const reference? Coudn't it make > problems when an temporary is used as the parameter? Const refernece has no sense with intrusive containers, because the value has to be modified. Temporaries can't bind to non-const references. > Possibly shift(integer how_much = 1) member could be added > that would move begin() and end(). > > Use case: list of tasks to be processed repeatedly. I'll think about this. > "Containers also know that the a value can be silently erased..." > - what does it mean "they know" - that empty() has worse O complexity? No just that they must cope with the fact that between two operations, the number of present nodes might have changed. For example, the size can't be internally stored (because it would be invalidated if an auto-unlink value operates between two operations). > * Example using BOOST_FOREACH could be added somewhere. I'm not a big fan of it ;-( > * Does Boost.Assign work with this library? No idea. But I plan to maintain the library without many dependencies or compile-time overhead. > * Does the library works together with Boost.Serialization? No. Deserialization would be also a problem. How will be the objects created? (intrusive containers don't manage memory) > * Does the library (in debug mode) detect adding the same > object multiple times into the same container? If you are use safe-mode or auto-unlink hooks, yes. > * perhaps a header with forward declarations could be added > into the library, like boost/intrusive_containers_fwd.hpp. Ok. > ________________________________________________________________ > EOF Thanks for your thorough review. Professional, as always, Regards, Ion

2 2

First principal component
by Johan Råde 23 Mar '07

23 Mar '07

Hej Erik, The first singular value is: 1.9071 The first principal component has the following values for each variable (PIP): -0.3288 -0.3763 -1.0907 0.9091 -1.5176 -0.7170 -1.6430 -1.1700 -0.2144 1.4566 0.2295 -0.7296 -1.0471 The first principal component has the following values for each sample (these are the ones you want to plot): 0.8878 0.9211 1.1391 0.8372 1.3336 0.8283 0.7192 0.7994 0.9854 1.5206 0.7769 0.9962 1.3031 0.8699 0.6403 --------------------------------------------------------- Example: This means that according this model, for instance, the logarithm of the relative expression value of the 1st gene for the 1st sample should be 1.9071 * -0.3288 * 0.8878 Similarly, the logarithm of the relative expression value of the 2nd gene for the 3rd sample should be 1.9071 * -0.3763 * 1.1391 --Johan

1 1

Google SoC 2007 - Plotting Graphs from C++ Containers in Scalable Vector Graphics (SVG) Format
by Kasun Rodrigo 23 Mar '07

23 Mar '07

Hello, I am a level 4 undergraduate of University of Moratuwa, Sri Lanka, following a Computer Science & Engineering Major. I'm very much interested in the above project idea. I have already developed a 2D and 3D graph plotting application in Visual Basic. I was dreaming of developing a graph plotting library in C++ that has the similar plotting features like famous application called MATLAB. * 2D plots * 3D plots (Mesh & Surface) * Pie charts, Bar Charts, etc.. * Axis labels, Scale, Grid, Legend * Multiple Graphs on the same figure. (Subplots) I would like to develop the solution in the following way. - Generic SVG library that exposes the primitive operations on SVG DOM - Graph plotting library - Generic plotting interface that exposes high level plotting operations to plot graphs from functions & C++ containers - A specific plotting implementation derived from generic one that uses the SVG library to carry out plotting operations. By doing it in above way I wish to improve the re-usability and theflexibilityof the code. 1. We can re-use the generic SVG library 2. Someone can derive different plotting libraries from generic one and use without changing the client code. (Eg:- Plot to screen, Plot to a document etc..) Can you please comment on above ideas. I'm looking forward for your kind comments. Thanks Kasun

3 4

[Boost-bugs] [ boost-Patches-1686705 ] [thread] thread_specific_ptr::element_type ?
by SourceForge.net 23 Mar '07

23 Mar '07

Patches item #1686705, was opened at 2007-03-23 12:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1686705&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gareth Sylvester-Bradley (gmsb) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] thread_specific_ptr::element_type ? Initial Comment: Would the following patch be useful? --- /boost_1_33_1/boost/thread/tss.hpp 2007-03-23 12:21:33.000000000 +0000 +++ /boost_1_33_1/boost/thread/tss.hpp.patched 2007-03-23 12:21:20.000000000 +0000 @@ -73,6 +73,8 @@ class thread_specific_ptr : private noncopyable { public: + typedef T element_type; + thread_specific_ptr() : m_tss(new boost::function1<void, void*>( boost::detail::tss_adapter<T>( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1686705&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Google SOC 2007, Boost.Test Frontend
by Younes M 23 Mar '07

23 Mar '07

Hi, I recently came across a suggestion for a Boost.Test frontend on the Google Summer of Code 2007 front page. As someone who uses Boost.Test a fair bit I think I would be very interested in persuing this. I have some early ideas about what I would like to see in a frontend, but would also love to get some ideas from others. I've emailed Thorsten Ottosen and he suggested I try here, so here I am. Along with the idea of having the frontend running in the systray and automatically capturing detecting and reporting on any unit tests that are run (as suggested on the Ideas page), I think being shown a list of failures and being jump to one such failure would be very handy. By "jump to" I mean having the source file open up in an editor and possibly even having the editor scroll to/highlight the line in question, or at the very least using a source-view widget in the front-end itself that could perform that function. If anyone has any other suggestions on functionality, information to include in generated reports, user interface, aesthetics, coupling between unit tests and the frontend, coupling between the frontend and editors, or on any other topic, I would love to hear it. Thank you for your time, Younes

13 29

[iostreams regressions] patches to fix msvc issues
by David Deakins 23 Mar '07

23 Mar '07

Since it seems like Jonathan Turkanis is not currently available to work on maintaining the iostreams library, perhaps someone else with CVS write access might apply the attached jamfile patches related to that library to RC_1_34_0 (if the release manager approves) and to HEAD. The description of the patches is below. These, along with the mentioned modification to the bzip2 DEF file, should resolve the remaining iostreams regressions. Once the jamfile patches are applied, I'll ping RudbekAssociates to delete their current test results, since I believe they run the regression tests incrementally and I don't think jamfile changes trigger a rebuild. Thanks, -Dave David Deakins wrote: > Douglas Gregor wrote: >> |iostreams| >> bzip2_test: msvc-7.1 msvc-8.0 >> gzip_test: msvc-7.1 msvc-8.0 >> zlib_test: msvc-7.1 msvc-8.0 >> > > I spent a little bit of time looking into the msvc-7.1 and msvc-8.0 > regressions for this library. It looks like the zlib and bzip2 > libraries used in these tests are being built from source files and it > appears that there are some omissions in the iostreams jamfile for > properly building them as DLLs in Windows. > > For zlib, there just needs to be a <link>shared:<define>ZLIB_DLL in > its build requirements so that the zlib source files use the > __declspec keyword on functions that should be exported. Without > this, no functions are exported and the import library file is not > created (thus the link errors). > > With bzip2, the basic problem is the same but its sources use a .DEF > file rather than __declspec (at least in the 1.0.4 sources that I > looked at). Adding <link>shared:<def-file>$(BZIP2_SOURCE)/libbz2.def > properly included the DEF file that gives the exports, but revealed > another problem. The DEF file has a 'LIBRARY LIBBZ2' line in it which > wants to give the DLL the name libbz2.DLL. Unfortunately the > iostreams jam file typically calls the library something like > boost_bzip2-vc80-mt-gd-1_34.DLL and specifies an /OUT directive to the > linker to ask for this name. At least on my machine with VC8, the > /OUT directive overrides the LIBRARY rule enough to make the intended > boost_bzip2-vc80-mt-gd-1_34.DLL file, but not enough to get this name > into the import .LIB file that boost_iostreams links to. As a result, > the iostreams library will compile and link, but will fail trying > locate libbz2.DLL (instead of the correct > boost_bzip2-vc80-mt-gd-1_34.DLL). The only way I could easily resolve > this was to comment out the LIBRARY rule in the libbz2.DEF file in the > bzip2 sources like so: > > ; LIBRARY LIBBZ2 > > With this change and the patches to the iostreams jamfile, building > zlib and bzip2 from sources works correctly and the 3 tests pass. I > attached a patch for jamfile.v2 in libs\iostream\build with my > changes. It might be good to put a note about the bzip2 .DEF file > change in the iostreams documentation. > > Incidently, using <def-file> revealed a small issue in msvc.jam > related to DEF file paths that have spaces in them. The linker > command does not put quotes around the DEF path like it does with most > of the other parameters, and as a result DEF paths with spaces will > cause the link to fail. I also included a patch to msvc.jam to add > quotes around DEF file paths. > > Thanks, > -Dave >

4 6

[atomic_count] Different behaviour on different platforms
by Hartmut Kaiser 23 Mar '07

23 Mar '07

Hi all, Is there a rational for the different behavior (signature) of the atomic_count::operator++()? This operator returns long (the new value) on Win32 and Solaris, but has no return type (void) on pthread and gcc based systems. Regards Hartmut

2 1

[sorting] Small error in multikey quicksort file
by Sam Schetterer 22 Mar '07

22 Mar '07

I just discovered that all of the functions in mkqsort.hpp are prefixed with callingcov, but at the top of the file, callingcov is accidentally defined as callingconv. When that is fixed, all code will compile nicely. Sorry.

1 0

Re: [boost] Boost.Threads, N2178, N2184, et al
by Emil Dotchevski 22 Mar '07

22 Mar '07

> <snip> > OK. But that doesn't really address my initial point: implementing call_once> in terms of the POSIX pthread_once is a bit pointless if you need to implement> pthread_once separately anyway. If you don't have pthread_once, I would write> call_once (or, equivalently pthread_once2_np), and implement pthread_once in> terms of that. Pthread is a C interface that has been implemented on many platforms already and I don't see why you think anyone would implement it over std::thread. It just won't happen. On the other hand, if a particular platform implements pthread (virtually all do, and we have Windows port of pthread which is a proof of concept at least), implementing the C++ portion of N2178 is a breeze. Pthread is there, standardized, proven in practice, so why not make use of it? In addition, there is a lot of legacy pthread code which N2178 makes compatible with future C++ <thread> based code. I consider both to be Good Things. Emil Dotchevski _________________________________________________________________ It’s tax season, make sure to follow these few simple tips http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.…

4 4

[sorting] Is there still interest?
by Sam Schetterer 22 Mar '07

22 Mar '07

Hi. I am just wondering if there is still interest in the library, because I have not recieved any comments on the library in the last two days, no posts at all, while I have made multiple posts, some with very important ideas in them.

5 8