Re: [boost] Small question about yes_type/no_type
Lately I never stop finding odd things into boost sources. Here's one
from type_traits/detail/yes_no_type.hpp:
typedef char yes_type;
struct no_type
{
char padding[8]; // --
};
Why '8'?
Why not ? as long as it's not 1 :-)
John.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] Doc edits
On Fri, 14 Mar 2003 12:10:52 -0600, David B. Held [EMAIL PROTECTED] wrote: First, it is functionally similar to a tristate boolean (false, maybe,true) -such as boost::tribool-, except that in a tristate boolean, the maybe state represents a valid value, unlike the corresponding state of an uninitialized optionalbool. I think two hyphens should be used for the em-dashes (or the actual em-dash character, which is probably not portable). Also, the comma after the em-dash is probably not necessary (even though it would be if the parenthetical phrase were not present). As far as English is concerned I'll leave the response to people who have studied in an English-speaking country, however I would be surprised if your rules *required* a comma before except in absence of the parenthetical phrase. Secondly, the comma just before the maybe state is definitely an error in Italian but, again, I'll leave to you to say if the same thing holds for English. The above notes would be of course off-topic in themselves but I think they aren't in this context, as they are meant as a rationale for proposing a correction to existing boost documentation. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] A generic tree manipulation library
Is there a library in boost that allows the manipulation of n-ary trees (including binary trees and arbitary branching trees as subsets of this). If so, does this have support for trie structures (a dictionary-like object where each level of the tree represents the nth letter in a word contained in it). Also, how do the iterators work? Is there a concept of moving across the siblings and moving up/down the tree? I have had a few ideas about implementing a library along these lines if none already exists. The idea is to add a new set of iterator categories: up_iterator -- has a function up() that moves the iterator *up* the container (in a kind of 2D space). down_iterator -- has a function down() to move the iterator *down* the container. updown_iterator -- has both an up() and down() function for moving across the y-axis of the container (like what the bidirectional_iterator is to the forward_iterator) Will it be better just to have the down and the updown iterators so it is more like the forward and bidirectional iterators? Can these types be added to other 2D-like containers (vector2d anyone???) The idea is to have general requirements for what constitutes a *tree node* that allows them to be manipulated and accessed in a common way - whether it is a binary tree node, an n-ary tree node using an array or an arbitary branching node using a linked list for siblings. There is plans to have a tree class that uses an implementation of a tree node, giving access to the root of the tree and possibly additional stuff. The tree class can then be used to implement a trie data structure, possibly as a trie_map (using the associative container interface to give the container very fast lookup) or as a seperate class that is used to implement trie_map, trie_multimap, trie_set and trie_multiset containers. Feedback would be greatly appreciated, Reece H Dunn -rhd- mailto:[EMAIL PROTECTED] _ MSN Messenger - fast, easy and FREE! http://messenger.msn.co.uk ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [type_traits] Missing comma in boost/type_traits/is_class.hpp
Hi there, The subject says it all (I'm using the CVS state from 5 minutes ago)... === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.6 diff -r1.6 is_class.hpp 84c84 ::boost::type_traits::ice_not ::boost::is_voidT::value ::value --- ::boost::type_traits::ice_not ::boost::is_voidT::value ::value, Thanks, Andreas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] GC
Would a library enabling Garbage Collecting be of any interest? Kevin _ MSN Search, le moteur de recherche qui pense comme vous ! http://fr.ca.search.msn.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [type_traits] Missing comma in boost/type_traits/is_class.hpp
Andreas Huber wrote: Hi there, The subject says it all (I'm using the CVS state from 5 minutes ago)... === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.6 diff -r1.6 is_class.hpp 84c84 ::boost::type_traits::ice_not ::boost::is_voidT::value ::value --- ::boost::type_traits::ice_not ::boost::is_voidT::value ::value, You are right. But I suggest not just to add the comma, but to remove the #if/#else/#endif-part it is found in, as both parts are identical now. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GC
Kevin Cadieux wrote: Would a library enabling Garbage Collecting be of any interest? Yes, but how does it compare with that in: http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/ ? In particular, see the just uploaded proxchildren-pattern.html. I couldn't upload the class and sequence diagrams referenced by that html file. I'll try later. I'm currently in midst of rewriting code; hence, it maybe better to wait, but the main advantages listed in that html file will still hold. (The file was created using docbook. Thanks to Douglas Gregor for paving the way in that area). ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Sat, 15 Mar 2003 11:10:57 -0600, David B. Held [EMAIL PROTECTED] wrote: Any ideas? boost::call_traitsU:: is a nondeduced context. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [call_traits] bcc failure
David B. Held wrote:
This code fails on bcc 5.5.1:
And for the gcc, too.
template typename U
foo(boost::call_traitsU::param_type v)
{ }
There is a 'typename' missing, but that won't help AFAICS.
[C++ Error] CallTraits.cpp(20): E2285 Could not find a match for
'foo::foo(X)'
Any ideas?
The compiler has no idea how to deduce U as - depending on U -
param_type could change. What happens if two different U's would be a
valid match? IIUC the standard forbids type-deduction is these cases to
avoid non-portable code, so if any other compiler would work, it would
IMHO not be standard conformant code.
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GC
Philippe A. Bouchard wrote: Larry Evans wrote: Kevin Cadieux wrote: [snip] It's pretty good. ip_assign_op_switch is faster than ip_offset_iterator but must be explicit? I was afraid of that(as indicated in 6.2.2 of the .html file); however, ip_offset_iterator is more robust (as indicated in 6.2.3 item 2). Maybe some boost template guru's could figure a way to hack a virtual template member function as mentioned in item 4 of 6.1.2. An index.html would be great; an objective point of view. I'm still working on it. I thought the uml was pretty clear, but I thought I just implement it to make sure I hadn't missed anything. Sure enough, I had. I'm working on the implementation now and will modify the doc's when that's done. Thanks for the feedback. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GC
I'm starting with this project so I can only give you a general description. The GC I am talking about would be omnipresent in the project and almost invisible to the user without affecting the control the programmer would have over it. It could obviously allow multiple instanciations so that the programmer can tune each of his GC's the way he wants to. That would boost up the performance in the case that a programmer would need to collect garbage differently without having to change back and forth the settings of a single GC instanciation. If the user wants to start using the GC right away without messing with settings, he/she could easily start it up using a function such as StartGC() (or whatever) which will use default settings. I'm waiting for your opinions, do not hesitate to ask your questions. Kevin _ MSN Search, le moteur de recherche qui pense comme vous ! http://fr.ca.search.msn.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GC
Kevin Cadieux wrote: I'm starting with this project so I can only give you a general description. The GC I am talking about would be omnipresent in the project and almost invisible to the user without affecting the control the programmer would have over it. It could obviously allow multiple instanciations so that the programmer can tune each of his GC's the way he wants to. That would boost up the performance in the case that a programmer would need Is it conservative? If not, how do you access the children of each vertex in the pointer graph? The multiple instantiations sounds similar to cmm (ftp://ftp.di.unipi.it/pub/project/posso/cmm ). If so, I think it's a good idea; however, I'm wondering how you'd mix, for example, rc with mark-sweep. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A generic tree manipulation library
[2003-03-15] Reece Dunn wrote: Is there a library in boost that allows the manipulation of n-ary trees (including binary trees and arbitary branching trees as subsets of this). No. But there was some previous discussion about Kasper Peeters tree implementation... http://lists.boost.org/MailArchives/boost/msg36876.php Boost Mailing List Archive -- [boost] any interest in a 'tree' container? I'm very interested in having tree container concepts in Boost. It's my plan to submit such a thing to Boost in the summer. Currently I only have a rank_tree implementation (log2 n, or better on all ops) so having someone else work on other types of tree implementations would be awsome ;-) If so, does this have support for trie structures (a dictionary-like object where each level of the tree represents the nth letter in a word contained in it). Haven't seen such a proposal here, yet. Along those same lines I also have a specialized version of a trie container, hex_part_dictionary, which stores nibles at each level of tree. But it would require a complete rewrite to be usefull to anyone, even to myself ;-\ Also, how do the iterators work? Is there a concept of moving across the siblings and moving up/down the tree? I have had a few ideas about implementing a library along these lines if none already exists. The idea is to add a new set of iterator categories: up_iterator -- has a function up() that moves the iterator *up* the container (in a kind of 2D space). down_iterator -- has a function down() to move the iterator *down* the container. updown_iterator -- has both an up() and down() function for moving across the y-axis of the container (like what the bidirectional_iterator is to the forward_iterator) My equivalent idea was to introduce a cursor concept that has all the various tree navigation operations. It would return clasic linear iterators for some things, like the children of the current node. Here are some ops for such a cursor: parent(), children(), rchildren(), left_children(), left_rchildren(), right_children(), right_rchildren(), etc. It then becomes very easy to write classical traversal algos in a generic form. Will it be better just to have the down and the updown iterators so it is more like the forward and bidirectional iterators? I'm of the opinion that the closer a tree container interface is to the standard linear iterators the less usefull it becomes as a tree structure. Can these types be added to other 2D-like containers (vector2d anyone???) The idea is to have general requirements for what constitutes a *tree node* that allows them to be manipulated and accessed in a common way - whether it is a binary tree node, an n-ary tree node using an array or an arbitary branching node using a linked list for siblings. There is plans to have a tree class that uses an implementation of a tree node, giving access to the root of the tree and possibly additional stuff. The tree class can then be used to implement a trie data structure, possibly as a trie_map (using the associative container interface to give the container very fast lookup) or as a seperate class that is used to implement trie_map, trie_multimap, trie_set and trie_multiset containers. Given the variety of ways to implement trees, both in storage and behaviour, I would lean towards making a generic tree concept that gets implemented by the variety of trees. As opposed to using a generic tree implementation to store other types of trees. This is because many of the tree implementations get their advantages from very special storage to improve speed. For example my hex_part_dictionary stores only 4bits of the data at each level to reduce the size of nodes and to reduce the single level branching to fit in a 16bit field. I need to be that efficient because I need to literally store a dictionary, as in something like Oxford English. Other things I've thought about include: * Having both functional and iterator versions of traversals. For example having both: inorder_traversal_iterator class, and inorder_traversal algorithm. The iterator would be constructed from a cursor and the algorithm would take a cursor and visitor function. ...I had others, but they escape me right at this moment :-( ... -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regressions in type_traits and lexical_cast (was: Re: [Boost-Users]Question about boost::function)
John, This regression in Function is coming from your recently change to is_class.hpp. Would you mind taking a look? On Saturday 15 March 2003 01:31 pm, Bernhard Glueck wrote: Hi ! I was using boost:function for a while now with success on Visual C 7.0 ( MSVC 1300 ) . I was always using the most actual boost 1.30.0 version from the CVS. Today i updated the CVS again ( after two days of not doing so ) and suddenly my code which relied on boost::function does not compile anymore. boost::function hasn't changed in the last few weeks, but some of the libraries it depends on have changed. I think there have some changes been made, so i need to change my code, but since there is no boost::function documentation in the CVS yet can someone please enlighten me what has changed .. ? FYI, updated documentation for Boost.Function is here: http://www.cs.rpi.edu/~gregod/boost/doc/html/function.html Also, it's on the RC_1_30_0 branch in CVS (that will be 1.30.0; mainline CVS is for 1.31.0 and later). Here is the relevant code: ( I have marked the line where compilation fails and provided the exact error details below ) ( This code compiled perfectly two days ago ) [snip code] /// /// VISUAL C ERROR OUTPUT: /// /// D:\Sdk\boost\boost\type_traits\is_class.hpp(78) : error C2510: 'value' : left of '::' must be a class/struct/union D:\Sdk\boost\boost\type_traits\is_class.hpp(94) : see reference to class template instantiation 'boost::detail::is_class_implT' being compiled with [ T=boost::any (__cdecl *)(const boost::any ) ] Looks like a type_traits problem. I suspect this patch: Index: is_class.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.5 retrieving revision 1.6 diff -r1.5 -r1.6 84a85 ::boost::type_traits::ice_not ::boost::is_functionT::value ::value John? // SECOND Problem As you may note all conversions from data types to std::string are commented out ! This is because boost::lexical_cast fails to compile in DEBUG mode ( it compiles fine in RELEASE Mode and also works like a charm in RELEASE mode ) The implementation of lexical_cast w.r.t. strings is in a state of flux. I'm too far out of the loop to be helpful on this one. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Sat, 15 Mar 2003 20:15:59 +0100, David B. Held wrote: Daniel Frey [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] The compiler has no idea how to deduce U as - depending on U - param_type could change. [...] Oh, yes, I see. I guess call_traits is only useful when T is a class template parameter. A bit unfortunate, isn't it? I mean, it isn't very useful for function forwarding then, is it? Indeed. And I don't see any solution for your problem (except manually providing the overloads you need). Bad luck :( Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Regressions in type_traits and lexical_cast (was: Re:Questionabout boost::function)
[ ... ] Index: is_class.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.5 retrieving revision 1.6 diff -r1.5 -r1.6 84a85 ::boost::type_traits::ice_not ::boost::is_functionT::value ::value John? This is due to the missing comma I reported in http://lists.boost.org/MailArchives/boost/msg45211.php Regards, Andreas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regressions in type_traits and lexical_cast (was: Re:Questionabout boost::function)
On Saturday 15 March 2003 06:03 pm, Andreas Huber wrote: [ ... ] Index: is_class.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.5 retrieving revision 1.6 diff -r1.5 -r1.6 84a85 ::boost::type_traits::ice_not ::boost::is_functionT::value :: ::value John? This is due to the missing comma I reported in http://lists.boost.org/MailArchives/boost/msg45211.php Regards, Andreas Ah, yes it is. I've applied the patch (actually, Daniel Frey's version: no need to duplicate code) on mainline and the RC_1_30_0 branch. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Regressions in type_traits and lexical_cast (was: Re:Questionabout boost::function)
Ah, yes it is. I've applied the patch (actually, Daniel Frey's version: no need to duplicate code) on mainline and the RC_1_30_0 branch. Thanks! :) Andreas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: GC
Larry Evans wrote: [...] It's pretty good. ip_assign_op_switch is faster than ip_offset_iterator but must be explicit? I was afraid of that(as indicated in 6.2.2 of the .html file); however, ip_offset_iterator is more robust (as indicated in 6.2.3 item 2). Maybe some boost template guru's could figure a way to hack a virtual template member function as mentioned in item 4 of 6.1.2. A virtual template member function. It looks like another virtual table will have to be gradually constructed at compile time, just like what I did last year with ptrT, complex_tree: http://groups.yahoo.com/group/boost/files/ptr/ptr.hpp.old. The table could return the address of the template member function given some class X and template parameter Y. Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0 still broken
As of about 3pm PST today the RC_1_30_0 branch is still broken under VC6 and 7.0: http://cci.lbl.gov/boost/results/1047771420/dailylog_win32_vc60_test http://cci.lbl.gov/boost/results/1047771420/dailylog_win32_vc70_test Is this on the radar of someone who could fix the failures? Ralf __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0 filesystem broken
Ok, I finally got all the junk straightened out. got a clean update for the RC instead of the mainline, and guess what? It looks like it cannot find ANY functions that purportedly are defined in filesystem. oh, compilerVC7.1 -- Build started: Project: SimpleSL, Configuration: Debug Win32 -- Compiling... main.cpp Linking... main.obj : error LNK2019: unresolved external symbol public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall boost::filesystem::path::leaf(void)const ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@XZ) referenced in function _main main.obj : error LNK2019: unresolved external symbol public: __thiscall boost::filesystem::directory_iterator::directory_iterator(class boost::filesystem::path const ) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@12@@Z) referenced in function _main main.obj : error LNK2019: unresolved external symbol public: __thiscall boost::filesystem::directory_iterator::directory_iterator(void) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]) referenced in function _main main.obj : error LNK2019: unresolved external symbol public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall boost::filesystem::path::native_directory_string(void)const ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@XZ) referenced in function _main main.obj : error LNK2019: unresolved external symbol bool __cdecl boost::filesystem::is_directory(class boost::filesystem::path const ) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@@Z) referenced in function _main main.obj : error LNK2019: unresolved external symbol public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall boost::filesystem::path::native_file_string(void)const ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@XZ) referenced in function _main main.obj : error LNK2019: unresolved external symbol bool __cdecl boost::filesystem::exists(class boost::filesystem::path const ) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@@Z) referenced in function _main main.obj : error LNK2019: unresolved external symbol class boost::filesystem::path __cdecl boost::filesystem::system_complete(class boost::filesystem::path const ) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@ABV312@@Z) referenced in function _main main.obj : error LNK2019: unresolved external symbol public: __thiscall boost::filesystem::path::path(char const *,enum boost::filesystem::path_format) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@12@@Z) referenced in function _main main.obj : error LNK2019: unresolved external symbol class boost::filesystem::path const __cdecl boost::filesystem::initial_path(void) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@XZ) referenced in function _main main.obj : error LNK2019: unresolved external symbol private: class boost::filesystem::path const __thiscall boost::filesystem::directory_iterator::m_deref(void)const ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@XZ) referenced in function public: class boost::filesystem::path const __thiscall boost::filesystem::directory_iterator::operator*(void)const ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@XZ) main.obj : error LNK2019: unresolved external symbol private: void __thiscall boost::filesystem::directory_iterator::m_inc(void) ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@AAEXXZ) referenced in function public: class boost::filesystem::directory_iterator __thiscall boost::filesystem::directory_iterator::operator++(void) ([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]) Debug/SimpleSL.exe : fatal error LNK1120: 12 unresolved externals Build log was saved at file://c:\Projects\Programming\personal\BoostTesting\SimpleSL\Debug\BuildLog.htm SimpleSL - 13 error(s), 0 warning(s) -- Done -- Build: 0 succeeded, 1 failed, 0 skipped Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
