- Boost - lists.boost.org

[Boost-bugs] [ boost-Support Requests-957850 ] boost for ARM platform?
by SourceForge.net 21 May '04

21 May '04

Support Requests item #957850, was opened at 2004-05-21 00:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=957850&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost for ARM platform? Initial Comment: mailto:peter.mason@dilithiumnetworks.com is writing ... Sorry if this has been discussed already, but I've only just joined. Something I'm building under an ARM toolchain/devkit requires Boost functionality, and thus needs a porting of boost to ARM platforms. I'm not even familiar with the build tools used to build Boost, so it's a daunting task. Can someone please tell me that such a port has been done already and it's available at XXX? If not, then I'd appreciate some options and guidance. Thanks in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=957850&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

enabling automatic memory leak detection with VC
by Robert Ramey 21 May '04

21 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

2 1

VC7.1 and BGL from cvs
by Victor A. Wagner Jr. 21 May '04

21 May '04

The following errors have been showing up in my nightly builds starting 2004 May 14 C:\Projects\boost>bjam -sTOOLS=vc7.1 install 1>bjaminstall.log ============ a section of the log file, hopefully relevant =================================== vc-C++ bin\boost\libs\python\build\boost_python.dll\vc7.1\debug\inheritance.obj inheritance.cpp C:\Projects\boost\boost\graph\adjacency_list.hpp(423) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(342) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' C:\Projects\boost\boost\graph\adjacency_list.hpp(459) : see reference to class template instantiation 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>' being compiled C:\Projects\boost\boost\graph\adjacency_list.hpp(432) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(342) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' C:\Projects\boost\boost\graph\adjacency_list.hpp(441) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(346) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' C:\Projects\boost\boost\graph\adjacency_list.hpp(450) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(346) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' CALL "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\VCVARS32.BAT" >nul "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\cl" /Zm800 -nologo -GX -c -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE /Z7 /Od /Ob0 /GX /GR /MDd /Op /Zc:forScope /Zc:wchar_t -I"bin\boost\libs\python\build" -I"C:\Projects\boost" -I"c:\python23\include" -Fo"bin\boost\libs\python\build\boost_python.dll\vc7.1\debug\inheritance.obj" -Tp"C:\Projects\boost\libs\python\build\../src/object/inheritance.cpp" ...failed vc-C++ bin\boost\libs\python\build\boost_python.dll\vc7.1\debug\inheritance.obj... ...skipped <@boost!libs!python!build\boost_python.dll\vc7.1\debug>boost_python-vc71-mt-gd-1_31.CMD for lack of <@boost!libs!python!build\boost_python.dll\vc7.1\debug>inheritance.obj... ...skipped <@boost!libs!python!build\boost_python.dll\vc7.1\debug>boost_python-vc71-mt-gd-1_31.dll for lack of <@boost!libs!python!build\boost_python.dll\vc7.1\debug>boost_python-vc71-mt-gd-1_31.CMD... Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

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

20 May '04

John Nagle wrote: > This looks rather complex for what it does. > > It might be helpful to define the user-visible >API first. Then worry about the implementation. The user-visible API that I am using is the basic_string API (C++98 21.3) along with operator const CharT *() and format( const CharT *, va_args ) to allow C-style string interoperability. There are also implementations of the C string API (string.h) to allow fixed_string to interface with C code. The requirements for fixed_string are: [1] prevent buffer overflow on a fixed capacity string (CharT[ n ]); [2] provide a basic_string interface -- this is where part of the complexity comes in [3] provide C-string functions (strcpy, strlen, etc.) [4] allow functions to operate on variable-capacity strings without resorting to template code -- this is where the rest of the complexity comes in My implementation meets the above requirements, although requirement [3] could be more fully implemented (I'm working on this). Requirements 2 and 3 are interface (API) requirements, defined in the C++98 and C90 standards, while 1 and 4 are interface requirements. Despite the basic_string interface being complex, I do not want to drop it (even if that would simplify the class considerably!) However, if there is a simpler way to meet these requirements then I'd be happy to see what it is. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

1 0

[license]
by David B. Held 20 May '04

20 May '04

Is this the canonical way to license a Boost library? // Copyright 20xx. I. M. Author // Use, modification, and distribution are subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or // copy at www.boost.org/LICENSE_1_0.txt) If we don't want to include the actual license text in the library itself (nor does it seem desirable, when distributed with all of Boost), does it make more sense to abbreviate it to: // Copyright 20xx. I. M. Author // Use, modification, and distribution are subject to the Boost Software // License, Version 1.0. (See www.boost.org/LICENSE_1_0.txt) And did we agree that "use, modification, and distribution" is sufficient, or do we need to mention something about display rights? 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

4 5

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