- Boost - lists.boost.org

RE: [boost] Re: static sized strings
by Reece Dunn 20 May '04

20 May '04

John Nagle wrote: >Reece Dunn wrote: >>I have uploaded an initial version of this. > Thanks. I'll take a look at that shortly. You might want to take a look at fixed_string.hpp. It is an alternate implementation of fixed_string that I intend to replace char_string.hpp once it is stable. Currently, this implementation is missing iterator support (and thus all basic_string functionality that relies on begin(), end(), etc). This is because I am wondering how to map them from the basic_string adaptor to the implementation (knowing that you cannot have const and non-const virtual functions). I have two possible solutions: [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the problem with this is that you have 8 virtual functions! [2] direct to non-const versions and convert to const iterators: inline const_iterator begin() const { return( const_iterator( const_cast< basic_string_impl & >( *this ).begin())); } but I am debating whether this is standards compliant and if it is a good design decision. If there are alternate solutions, I'd like to hear them. Another possibility would be to construct the iterators from offsets: inline iterator begin() { return( get_impl().iter_offset( 0 )); } inline reverse_iterator rbegin() { return( reverse_iterator( get_impl().iter_offset( size() - 1 ))); } That way you would only need two functions (iter_offset and const_iter_offset). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 3

RE: [boost] enabling automatic memory leak detection with VC
by Max Khesin 20 May '04

20 May '04

I also used this idom, it is very nice. One thing to watch out for is 'false positives' from other global/static objects that do mallocs. leak_reporter leak_reporter::instance; std::string i_will_trigger_leak_report; I am not aware of any automatic way to avoid this. m > -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: Thursday, May 20, 2004 2:06 PM > To: boost(a)lists.boost.org > Subject: [boost] enabling automatic memory leak detection with VC > > > While investigating shared_ptr serialization, I've come upon > the VC method > used for detecting memory leaks. I had previously used it as > part of MFC > and found it very helpful. By including the following at the > beginning of > one's test program: > > #define _CRTDBG_MAP_ALLOC > #include <stdlib.h> > #include <crtdbg.h> > > struct leak_reporter { > static leak_reporter instance; > leak_reporter(){ > _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | > _CRTDBG_LEAK_CHECK_DF ); > } > ~leak_reporter(){ > // _CrtDumpMemoryLeaks(); // replaced by the above > } > }; > leak_reporter leak_reporter::instance; > > The program displays the following in the output window while > running under > the VC IDE: > > Detected memory leaks! > Dumping objects -> > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {663} normal block at 0x00325480, 24 bytes long. > Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {393} normal block at 0x003261F0, 24 bytes long. > Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > Object dump complete. > > The sequential number (663 and 393 in this example) can be > used to trap the > debugger at the original allocation when the test is run the > next time. > > Is this not a worthy idea to be included in the test system - > at least for > VC? In this way we would get a report of memory leaks every > time we ran a > test. > > Robert Ramey > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

RE: [boost] Re: Is there interest in a decimal floating-point cla ss?
by Max Khesin 20 May '04

20 May '04

No I can't so I recant :). m. > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Thursday, May 20, 2004 2:14 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Is there interest in a decimal floating-point cla > ss? > > > Max Khesin <MKhesin(a)liquidnet.com> writes: > > > I would think the crucial difference is that pthreads pretty much > > come with the platform, while the C decimal math lib would have to > > be included with its wrapper's distribution from boost to insure > > availability - correct me if I am wrong. > > Unless you can cite an actual library guideline somewhere that rules > out such a wrapper, I guess you're wrong to "doubt boost library > guidelines would allow including a wrapper over a C library." > Parts of uBlas work that way with FORTRAN libraries, IIUC. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

3 2

RE: [boost] enabling automatic memory leak detection with VC
by Rozental, Gennadiy 20 May '04

20 May '04

> I also used this idom, it is very nice. One thing to watch > out for is 'false positives' from other global/static objects > that do mallocs. > > leak_reporter leak_reporter::instance; > std::string i_will_trigger_leak_report; > > > I am not aware of any automatic way to avoid this. I will use command line argument to to turn this feature on/off Gennadiy.

1 0

RE: [boost] enabling automatic memory leak detection with VC
by Rozental, Gennadiy 20 May '04

20 May '04

> While investigating shared_ptr serialization, I've come upon > the VC method used for detecting memory leaks. I had > previously used it as part of MFC and found it very helpful. > By including the following at the beginning of one's test program: > > #define _CRTDBG_MAP_ALLOC > #include <stdlib.h> > #include <crtdbg.h> > > struct leak_reporter { > static leak_reporter instance; > leak_reporter(){ > _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | > _CRTDBG_LEAK_CHECK_DF ); > } > ~leak_reporter(){ > // _CrtDumpMemoryLeaks(); // replaced by the above > } > }; > leak_reporter leak_reporter::instance; > > The program displays the following in the output window while > running under the VC IDE: > > Detected memory leaks! > Dumping objects -> > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {663} normal block at 0x00325480, 24 bytes long. > Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {393} normal block at 0x003261F0, 24 bytes long. > Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > Object dump complete. > > The sequential number (663 and 393 in this example) can be > used to trap the debugger at the original allocation when the > test is run the next time. > > Is this not a worthy idea to be included in the test system - > at least for VC? In this way we would get a report of memory > leaks every time we ran a test. > > Robert Ramey Thanks Robert, I will look onto it. Gennadiy.

1 0

RE: [boost] Re: Is there interest in a decimal floating-point cla ss?
by Max Khesin 20 May '04

20 May '04

I would think the crucial difference is that pthreads pretty much come with the platform, while the C decimal math lib would have to be included with its wrapper's distribution from boost to insure availability - correct me if I am wrong. m > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Thursday, May 20, 2004 11:41 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Is there interest in a decimal floating-point > class? > > > Max Khesin <MKhesin(a)liquidnet.com> writes: > > > I think this is very valuable, but I really doubt boost > library guidelines > > would allow including a wrapper over a C library, as the C > library certainly > > would not be confirming with boost coding (and possibly licensing) > > standards. Perhaps you should propose your wrapper as the > library interface, > > if you are willing to reimplement the guts later. > > I don't think that's neccessarily a problem. Boost.Threads is "just a > wrapper" over the pthreads library on some platforms. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

ETI bug
by David B. Held 20 May '04

20 May '04

Is VC 6.x the only compiler with this bug? Or does 7.x also have problems? How about compilers from other vendors? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004

6 7

RE: [boost] Is there interest in a decimal floating-point class?
by Max Khesin 20 May '04

20 May '04

I think this is very valuable, but I really doubt boost library guidelines would allow including a wrapper over a C library, as the C library certainly would not be confirming with boost coding (and possibly licensing) standards. Perhaps you should propose your wrapper as the library interface, if you are willing to reimplement the guts later. m > -----Original Message----- > From: Richard Kaiser [mailto:rk@rkaiser.de] > Sent: Thursday, May 20, 2004 9:03 AM > To: boost(a)lists.boost.org > Subject: [boost] Is there interest in a decimal floating-point class? > > > I want to ask the boost community if there is interest in a decimal > floating-point class implementing one or more of the decimal > floating-point types that are intended to become part of a > future C and > C++ standard. > > This class would be a wrapper class around Mike Cowlishaws > decNumber C > library. You can take a look at my first preliminary version > (it is just > a first try, the design is far from perfect, it is incomplete, its > notation is inconsistent and not according to boost conventions) at > > http://www.rkaiser.de/rkaiser/DecFPClass/DecFPClass.html > > Most of its operators work as they should do, and most of Mikes > testcases pass successfully. The function > DecimalFloat_Testcases("d:\\cpp.boo\\decnumber\\decnumberclass \\decTest\\") in my test program test_rk reads all the testcases from Mikes decTest files and logs each testcase in a file (bcb files were created with Borland C++Builder 6, gcc with MinGW g++, and msc with MS Visual Studio ..Net). With “grep "###number" *.log” you get the summary lines: File abs.decTest_bcb.log: ###number of tests passed=87 failed=2 File abs.decTest_gcc.log: ###number of tests passed=87 failed=2 File abs.decTest_msc.log: ###number of tests passed=87 failed=2 File add.decTest_bcb.log: ###number of tests passed=773 failed=45 File add.decTest_gcc.log: ###number of tests passed=773 failed=46 File add.decTest_msc.log: ###number of tests passed=773 failed=45 ... If the boost community is interested, if I find enough time, and if everything works as intended, the resulting classes would be a reference implementation for the new standard decimal floating point types, or at least a close one. I posted this request already some days ago, but by mistake I have posted it as a reply to a message it did not belong to. Sorry. Richard Kaiser _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

[assert_no_intrinsic_wchar_t] What the...?
by David Abrahams 20 May '04

20 May '04

The logic used here seems to be completely and totally broken. Was it even tested? config/compiler/intel.hpp first says: #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else ... #endif So if I have intel6, BOOST_NO_INTRINSIC_WCHAR_T is now set. Then config/compiler/intel.hpp goes on to say: #if defined(BOOST_NO_INTRINSIC_WCHAR_T) #include <cwchar> template< typename T > struct assert_no_intrinsic_wchar_t; template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; }; // if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T: typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_; #else ... #endif So, if I get the error, how exactly am I supposed to "unset BOOST_NO_INTRINSIC_WCHAR_T" before the error occurs? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 11

seiralization of shared_ptr
by Robert Ramey 20 May '04

20 May '04

Some time ago the question was raised on this list as to why it was necessary to access share_count in order to implement serialization of shared_ptr. At the time I didn't have an answer. So I went back and tried to re-implement it and have come to the following point beyond which I can't proceed without manipulating shared_count directly. ///////////////////////////////////////////////////////////// // implement serialization for shared_ptr<T> template<class Archive, class T> inline void save( Archive & ar, const shared_ptr<T> & t, const unsigned int /* file_version */ ){ ar << boost::serialization::make_nvp("px", t.get()); } template<class Archive, class T> inline void load( Archive & ar, shared_ptr<T> & t, const unsigned int /* file_version */ ){ // object tracking guarantees that pointers are not replicated // on loading. T * t_new; ar >> boost::serialization::make_nvp("px", t_new); // if its not the first time, it should be equal to the current pointer assert(0 == t.use_count() || t.get() == t_new); // assign new pointer or bump reference count as appropriate // ???? - what goes here? } Can anybody tell me "what goes here?" Robert Ramey

3 2