- Boost - lists.boost.org

[serialization] possible bug writing to text_oarchive
by rodolfo＠rodsoft.org 24 Mar '06

24 Mar '06

Hi, I use boost::serialization a lot to marshall c++ structures to be sent to a socket, like this: void send_update(ostream &out, const data_t &data) { { text_oarchive oa(out); oa << data; } out << "220 OK" << endl; } The problem is that text_oarchive doesn't append a blank character to denote the end of its data. If the last member sent to the oarchive is an unsigned 123 number, in this example the data sent would be ... (begining of data)... 123220 OK<CR> When processing this with text_iarchive, the last member gets the value 123220, instead of 123. By appending an space (or \n) to the end, in ~text_oarchive, this problem is solved. Another worst problem is if the receiver uses blocking socket connection (and no 220 OK is sent). After reading the last digit (3), it would wait for the next one, which wouldn't arrive, blocking the connection. By having an space after the last digit, it would know that the data stream has ended and it wouldn't block anymore. I've wasted the whole day figuring why my application was blocking :( Thanks, Rodolfo Lima _______________________________________________________ Yahoo! Acesso Gr�tis - Internet r�pida e gr�tis. Instale o discador agora! http://br.acesso.yahoo.com

2 2

[Boost-bugs] [ boost-Bugs-1457384 ] Doc typo for boost::extent
by SourceForge.net 23 Mar '06

23 Mar '06

Bugs item #1457384, was opened at 2006-03-24 00:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1457384&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: type_traits Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alberto Barbati (iaanus) Assigned to: John Maddock (johnmaddock) Summary: Doc typo for boost::extent Initial Comment: The first example provided in the documentation of boost::extent reads extent<int[1]> inherits from integral_constant<std::size_t, 0>. should be instead: extent<int[1]> inherits from integral_constant<std::size_t, 1>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1457384&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Building Boost 1.31 for x64 with Visual Studio 2005
by Terence Wilson 23 Mar '06

23 Mar '06

I've successfully built the 32 bit libraries for Windows, however, I cannot figure out how to build for 64 bit Windows. I'm particularly interested in using the serialization libraries. After Googling around I found a few others asking about x64, but no definitive answers. Help much appreciated.

2 1

[Boost-bugs] [ boost-Bugs-1457205 ] shared_ptr<> causes memory leacks and crash
by SourceForge.net 23 Mar '06

23 Mar '06

Bugs item #1457205, was opened at 2006-03-23 19:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1457205&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vladislav Lazarenko (vlazarenko) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr<> causes memory leacks and crash Initial Comment: I have written this small test to reproduce the bug. Please see.. #include <cstddef> #include <boost/shared_ptr.hpp> #include <boost/test/unit_test.hpp> using namespace std; using namespace boost; using namespace boost::unit_test_framework; class A; class B { public: B(boost::shared_ptr<A> ptr) : ptr_(ptr) {} ~B() {} private: boost::shared_ptr<A> ptr_; }; class A { public: A(int value) : value_(value) {} ~A() {} private: int value_; }; void test_shared_ptr() { BOOST_CHECKPOINT("Testing shared pointer..."); shared_ptr<A> a1(new A(10)); { shared_ptr<B> b1 = a1->create(); } { shared_ptr<B> b1 = a1->create(); } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1457205&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [quickbook] [MPL] Knowing where you are the wrong way
by David Abrahams 23 Mar '06

23 Mar '06

Joel de Guzman <joel(a)boost-consulting.com> writes: > David Abrahams wrote: > >> I don't have a big problem with self-linking for a heading that isn't >> in the TOC. > > The only heading that's in the TOC in the MPL docs is > the one at the top of the page. That's only because of the particular relationship between heading levels, which entries are in the TOC, and the way the pages get broken down. Is that the only/right way to do it? > For that, as Daryle noted, > there's a simpler way to grab the URL: get it from the > address bar. > > I don't care so much about that topmost heading. I care > about the ones down under. It just so happens that with > BoostBook, you can't really know in advance which headings > will be a top-page heading. In BoostBook, the user has control > over the chunking of the pages to html. You can, for example have > it all dumped into one big html file or small, fine grained > html files. So, QuickBook does not really have any knowledge > if it's a top-page section or not, and change the behavior > accordingly. XSLT has that knowledge, though, so the smarts > can be moved there. However, I don't quite like having different > behavior for top-headings and sub-headings. IMO, we should have > one and only one behavior for all headings, else kill it > altogether. > >> Maybe the only right way to resolve this in the end is to get Jonathan >> Turkanis' menu control integrated with BoostBook. > > Maybe :) Or the one Vladimir pointed out. Sure, but that doesn't help me with locating myself "in context" when browsing. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Patches-1446468 ] Fixes for build on IBM pSeries for AIX and Linux
by SourceForge.net 23 Mar '06

23 Mar '06

Patches item #1446468, was opened at 2006-03-09 14:32 Message generated for change (Comment added) made by biochimia You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1446468&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes for build on IBM pSeries for AIX and Linux Initial Comment: This is a fix to allow building Boost on pSeries to work better. This fixes problem with the building of dynamic libraries and shared objects. It also adds a bunch of the latest option supported by the V8 compiler. This unified diff patch has been tested on 1.33.1 and CVS. ---------------------------------------------------------------------- >Comment By: JoÃ£o Abecasis (biochimia) Date: 2006-03-23 17:45 Message: Logged In: YES user_id=840777 This is a duplicate of issue [1446471] and dgregor has already commented on that one. Closing this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1446468&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Patches status
by Marshall Clow 23 Mar '06

23 Mar '06

These are the submitted patches that are waiting to be integrated/rejected/whatever. Thanks to everyone who has helped! As always, if you see one that is mis-assigned, or you think that one marked "nobody" is right for you, please don't hesitate to jump in. ;-) Thank you for your cooperation! Patches per assignee: Jonathan Turkanis 4 Robert Ramey 1 Ronald Garcia 1 Here are the currently submitted patches, sorted by assignee. Assignee: ramey <http://sourceforge.net/users/ramey/> Summary: Boost.Serialization for std::bitset Bug #: 1029258 <http://sourceforge.net/tracker/index.php?func=detail&aid=1029258&group_id=7…> Assignee: rgarcia <http://sourceforge.net/users/rgarcia/> Summary: [concept_check.hpp] remove unused variable warning in msvc Bug #: 1388901 <http://sourceforge.net/tracker/index.php?func=detail&aid=1388901&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational::operator< fails for unsigned value types Bug #: 1434821 <http://sourceforge.net/tracker/index.php?func=detail&aid=1434821&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational.hpp::gcd returns a negative value sometimes Bug #: 1438626 <http://sourceforge.net/tracker/index.php?func=detail&aid=1438626&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational::operator<(rational) fails due to overflow Bug #: 1438991 <http://sourceforge.net/tracker/index.php?func=detail&aid=1438991&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: iostreams // file_descriptor::seek BUG on files > 4 GB Bug #: 1452698 <http://sourceforge.net/tracker/index.php?func=detail&aid=1452698&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Re: [boost] [quickbook] [MPL] Knowing where you are the wrong way
by David Abrahams 23 Mar '06

23 Mar '06

Joel de Guzman <joel(a)boost-consulting.com> writes: >>>AFAICT, there is no way to know that if the heading itself is >>>not self linked. >> Sure there is. You click the link, which takes you to a page with a >> TOC entry that points to the heading. Then you right-click the TOC >> entry and copy the link location. > > No! Try to get the "Invariants" heading in that page. You > can't. It is not listed in your TOCs to begin with. I don't have a big problem with self-linking for a heading that isn't in the TOC. >>>The only way is to link to the page and say, "ok, please go to >>>link http://tinyurl.com/omouw and see section Invariants." How >>>usable is that? The user will have to search a potentially long >>>page for the particular /Invariants/ section. 1) Imagine if the >>>page is long. 2) What if there are more than one /Invariants/ >>>in various sub-sections? >> Yes, it's a useful tool. I just think it's worth one more click >> from >> you in order to make the link generally useful for browsing users. > > Even if "Invariants" is listed in your TOC, then you still have > a problem. Imagine that you have all your functions doc'd in > a section. Imagine all those functions have an "Invariant" > subsection. I click the "Invariant" heading, it leads me to the > TOC, I find a long list with lots of headings with the same > "Invariants" title. Which will I choose? The one right at the top of the window (unless the page is short, in which case it takes a little care). > I'll have to look carefully. That's what I mean by error prone. It's only error-prone for the person trying to capture a link to the section header. The person browsing who wants to see the current context doesn't try to grab that link, so there's no error. Maybe the only right way to resolve this in the end is to get Jonathan Turkanis' menu control integrated with BoostBook. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Bugs-1456780 ] ambiguous overloads in boost::variant source code
by SourceForge.net 23 Mar '06

23 Mar '06

Bugs item #1456780, was opened at 2006-03-23 01:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1456780&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ambiguous overloads in boost::variant source code Initial Comment: I cannot figure out, why the following little program does not compile. It simply typedefs a variant of a specific bounded type set and then derives a class from this type. I've tried to compile it with VC 2005. It does not compile because of ambiguous overloads within the boost::variant source. It would be very helpful if somebody could shed light on the issue. Best regards Peter PS: I intended to post this to the boost developers list, but I was unable to log onto the list today. ************************************************************* #include <boost/variant.hpp> typedef boost::variant<char, int, double> numeric_type_variant; class numeric_type : public numeric_type_variant { public: /// Default constructor. numeric_type() : numeric_type_variant() { } template <typename T> /// Converting constructor. numeric_type(T const& t) : numeric_type_variant(t) { } // some more code }; int main(int argc, char* argv[]) { char ba; int bb; double bc; numeric_type a; numeric_type b(ba); numeric_type c(bb); numeric_type d(bc); a = ba; a = bb; a = bc; return 0; } ************************************************************* This is the build log: ------ Build started: Project: test_variant, Configuration: Debug Win32 ------ Compiling... test_variant.cpp c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1342) : error C2666: 'boost::variant<T0_,T1,T2>::convert_construct' : 2 overloads have similar conversions with [ T0_=char, T1=int, T2=double ] c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1327): could be 'void boost::variant<T0_,T1,T2>::convert_construct<char,int,double,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>(const boost::variant<T0_,T1,T2> &,long)' with [ T0_=char, T1=int, T2=double ] c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1258): or 'void boost::variant<T0_,T1,T2>::convert_construct<const T>(T &,int,boost::mpl::false_)' with [ T0_=char, T1=int, T2=double, T=numeric_type ] while trying to match the argument list '(const numeric_type, long)' c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1580) : see reference to function template instantiation 'boost::variant<T0_,T1,T2>::variant<T>(const T &)' being compiled with [ T0_=char, T1=int, T2=double, T=numeric_type ] c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1590) : see reference to function template instantiation 'void boost::variant<T0_,T1,T2>::assign<T>(const T &)' being compiled with [ T0_=char, T1=int, T2=double, T=numeric_type ] c:\_schrott\test_variant\test_variant\test_variant.cpp(36) : see reference to function template instantiation 'boost::variant<T0_,T1,T2> &boost::variant<T0_,T1,T2>::operator =<numeric_type>(const T &)' being compiled with [ T0_=char, T1=int, T2=double, T=numeric_type ] Build log was saved at "file://c:\_schrott\test_variant\test_variant\Debug\BuildLog.htm" test_variant - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1456780&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[1.34] Release Branch
by Thomas Witt 23 Mar '06

23 Mar '06

FYI, we now have a RC_1_34_0 branch. Please focus on resolving the remaining issues on this branch. Thanks Thomas -- Thomas Witt witt(a)acm.org

4 4