- Boost-users - lists.preview.boost.org

RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C:
by Dernoncourt, Wayne CTR NAVAIR 3184, ,10 06 Feb '04

06 Feb '04

Well that worked much better as far as it went (747 updated files out of 747 targets wth no skipped files and no failures). The version of the bjam binary was a little larger (~5k) than the one I compiled<scratches head>, but using this produced no errors. Unfortunately we still have at least a few problems. As I described originally we are using a highly specialized third party SDK. Part of this SDK redefines reverse_iterator (as well as min & max) evidently the MS Visual C++ reverse iterator is broken in some way. From a cursory examination of the two implementations, it appears that both the two are very similiar in functionality if not implementation. The issue with min/max could be eliminated by commenting out line 59 of boost/config/stllib/dinkumware.hpp (line defines BOOST_NO_STD_MIN_MAX). There doesn't appear to be a similiar line for the reverse iterator. One of the issues appears to be that this third party SDK doesn't seem to use namespaces for the SDK. From my limited understanding, for namespaces to be used effectively, the different libraries/SDK's would need to be in their own namespaces. If Boost had theirs and the third party used the global namespaces, there could still be conflicts. Is my understanding correct? -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Administrator Sent: Thursday, February 05, 2004 15:11 To: 'Boost Users mailing list' Subject: RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: Binaries of bjam are released separately. You can actually download a binary of bjam for nt at the bottom of the Sourceforge download page here: http://sourceforge.net/project/showfiles.php?group_id=7586 Also get the latest version (1.31.0) of boost as it has an easier install stage. The command-line should be: bjam "-sTOOLS=msvc" "-sMSVC_ROOT=D:\Progra~1\Micros~1" You can avoid all that if you execute vcvars32.bat and then do: bjam "-sTOOLS=msvc" That should si

1 0

Mac OS 10.3.2 Compiling Problems.
by Pierre-Michel Tremblay 06 Feb '04

06 Feb '04

Bonjour, I'm new to Boost. My platform is a PowerBook G4 running Mac OS X 10.3.2 with the following: [champignac:~] ptrembla% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) -downloaded boost-1.31.0.tar.gz -downloaded boost-jam-3.1.9.tgz -created a directory in ~/CVSROOTs and moved the two downloaded files there. -expanded downloaded boost-jam-3.1.7.tgz and ran build.sh -moved the executables created in ~/CVSROOTs/boost-jam-3.1.9/bin.macosxppc to /usr/bin -expanded boost-1.31.0.tar.gz and went to directory with jam files [champignac:~] ptrembla% cd /Users/ptremblay/CVSROOTs/boost_1_31_0 [champignac:~/CVSROOTs/boost_1_31_0] ptrembla% ls Jamfile boost.css people Jamfile.v2 c++boost.gif project-root.jam Jamrules doc rst.css LICENSE_1_0.txt google_logo_40wht.gif status README index.htm tools boost libs boost-build.jam more -set up my environment variables relating to Python within ~/.cshrc, i.e. set PYTHON_ROOT="/usr/bin/python" set PYTHON_VERSION="2.3" [champignac:~/CVSROOTs/boost_1_31_0] ptrembla% which python /usr/bin/python [champignac:~/CVSROOTs/boost_1_31_0] ptrembla% python -V Python 2.3 -ran bjam -sTOOLS=darwin [champignac:~/CVSROOTs/boost_1_31_0] ptrembla% which bjam /usr/bin/bjam [champignac:~/CVSROOTs/boost_1_31_0] ptrembla% cd /Users/ptremblay/CVSROOTs/boost_1_31_0 [champignac:~/CVSROOTs/boost_1_31_0] ptrembla% bjam -sTOOLS=darwin --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "/System/Library/Frameworks/Python.framework/Versions/2.2/include/ python2.2" You can configure the location of your python installation by setting: PYTHON_ROOT - currently "/System/Library/Frameworks/Python.framework/Versions/2.2" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_LIB_PATH - path to Python library object; currently PYTHON_INCLUDES - path to Python #include directories; currently "/System/Library/Frameworks/Python.framework/Versions/2.2/include/ python2.2" --------------------------------------------------------------------- ...patience... ...found 4834 targets... ...updating 315 targets... {Output cut here} MkDir1 bin/boost/libs/test MkDir1 bin/boost/libs/test/build MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/ shared-linkable-true darwin-C++-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/ shared-linkable-true/execution_monitor.o darwin-C++-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/ shared-linkable-true/cpp_main.o darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/ shared-linkable-true/libboost_prg_exec_monitor-d-1_31.dylib ld: Undefined symbols: cpp_main(int, char**) DYLD_LIBRARY_PATH=bin/boost/libs/test/build/ libboost_prg_exec_monitor.dylib/darwin/debug/shared-linkable-true export DYLD_LIBRARY_PATH ld -dynamic -m -r -d -o "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ debug/shared-linkable-true/libboost_prg_exec_monitor-d-1_31.lo" "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ debug/shared-linkable-true/execution_monitor.o" "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ debug/shared-linkable-true/cpp_main.o" \ && \ c++ -g -Wl,-dynamic -nostartfiles -Wl,-dylib -Wl,-ldylib1.o -o "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ debug/shared-linkable-true/libboost_prg_exec_monitor-d-1_31.dylib" "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ debug/shared-linkable-true/libboost_prg_exec_monitor-d-1_31.lo" \ \ \ && \ rm -f "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ debug/shared-linkable-true/libboost_prg_exec_monitor-d-1_31.lo" ...failed darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/debug/ shared-linkable-true/libboost_prg_exec_monitor-d-1_31.dylib... MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true darwin-C++-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/execution_monitor.o darwin-C++-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/cpp_main.o darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/libboost_prg_exec_monitor-1_31.dylib ld: Undefined symbols: cpp_main(int, char**) DYLD_LIBRARY_PATH=bin/boost/libs/test/build/ libboost_prg_exec_monitor.dylib/darwin/release/shared-linkable-true export DYLD_LIBRARY_PATH ld -dynamic -m -r -d -o "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/libboost_prg_exec_monitor-1_31.lo" "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/execution_monitor.o" "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/cpp_main.o" \ && \ c++ -Wl,-x -Wl,-dynamic -nostartfiles -Wl,-dylib -Wl,-ldylib1.o -o "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/libboost_prg_exec_monitor-1_31.dylib" "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/libboost_prg_exec_monitor-1_31.lo" \ \ \ && \ rm -f "bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/libboost_prg_exec_monitor-1_31.lo" ...failed darwin-Link-DyLib-action bin/boost/libs/test/build/libboost_prg_exec_monitor.dylib/darwin/ release/shared-linkable-true/libboost_prg_exec_monitor-1_31.dylib... {Output cut here} ...failed updating 6 targets... ...updated 309 targets... QUESTIONS Are these failures "normal"? If not, what can I do to make it compile correctly? What should I do to make Boost.Python to compile correctly with 2.3? Where are the files I should rectify to solve these errors? Many thanks. Pierre-Michel

1 0

Errors with #include "boost/test/included/test_exec_monitor.hpp"
by Shawn Church 05 Feb '04

05 Feb '04

I am having problems compiling using the included form of the test execution monitor library. I have not tried building the library seperately and linking. The following test illustrates the problem: #include "boost/test/included/test_exec_monitor.hpp" int test_main(int argc, char *argv[]) { BOOST_CHECK("TEST ME"); } /* When used with boost 1.30.2 Building Makefile: "C:\Dev-Cpp\Local\sql\Mingw32\Makefile.win" Executing make... make.exe -f "C:\Dev-Cpp\Local\sql\Mingw32\Makefile.win" all g++.exe -c ../src/test_main.cpp -o ../src/test_main.o -I"C:/Dev-Cpp/include/c++" -I"C:/Dev-Cpp/include/c++/mingw32" -I"C:/Dev-Cpp/include/c++/backward" -I"C:/Dev-Cpp/include" -I"C:/Dev-Cpp/Local/boost-1.30.2" <<<<< The only change is here. -fexceptions -fmessage-length=0 g++.exe ../src/test_main.o -o "Sql.exe" -L"C:/Dev-Cpp/lib" ../../../lib/libodbc32.a Execution terminated Compilation successful Output: Platform: Win32 Compiler: GNU C++ version 3.2 (mingw special 20020817-1) STL : GNU libstdc++ version 20020816 Boost : 1.30.2 Entering test case "call_test_main" ../src/test_main.cpp(5): info: test "TEST ME" passed C:/Dev-Cpp/Local/boost-1.30.2/libs/test/src/test_main.cpp(40): error in "call_test_main": test test_main_result == 0 || test_main_result == boost::exit_success failed Leaving test case "call_test_main" Test case "call_test_main" failed with: 1 assertion out of 2 passed 1 assertion out of 2 failed When compiling with 1.31.0 Compiler: Default compiler Building Makefile: "C:\Dev-Cpp\Local\sql\Mingw32\Makefile.win" Executing make... make.exe -f "C:\Dev-Cpp\Local\sql\Mingw32\Makefile.win" all g++.exe -c ../src/test_main.cpp -o ../src/test_main.o -I"C:/Dev-Cpp/include/c++" -I"C:/Dev-Cpp/include/c++/mingw32" -I"C:/Dev-Cpp/include/c++/backward" -I"C:/Dev-Cpp/include" -I"C:/Dev-Cpp/Local/boost_1_31_0" <<< The only change is here !!!!! -fexceptions -fmessage-length=0 In file included from C:/Dev-Cpp/include/boost/test/included/test_exec_monitor.hpp:20, from ../src/test_main.cpp:1: C:/Dev-Cpp/Local/boost_1_31_0/libs/test/src/execution_monitor.cpp:185: no `int boost::execution_monitor::run_function()' member function declared in class `boost::execution_monitor' C:/Dev-Cpp/Local/boost_1_31_0/libs/test/src/execution_monitor.cpp: In member function `int boost::execution_monitor::run_function()': C:/Dev-Cpp/Local/boost_1_31_0/libs/test/src/execution_monitor.cpp:186: `m_custom_translators' undeclared (first use this function) C:/Dev-Cpp/Local/boost_1_31_0/libs/test/src/execution_monitor.cpp:186: (Each undeclared identifier is reported only once for each function it appears in.) .... I deleted 100+ lines of errors here .... C:/Dev-Cpp/include/boost/test/detail/unit_test_monitor.hpp:51: `target_test_case_' undeclared (first use this function) C:/Dev-Cpp/include/boost/test/detail/unit_test_monitor.hpp:51: only constructors take base initializers C:/Dev-Cpp/include/boost/test/detail/unit_test_monitor.hpp:51: confused by earlier errors, bailing out make.exe: *** [../src/test_main.o] Error 1 Execution terminated */ I rechecked the release notes for the test library and did not see any reason why the above should not work. Maybe i am just missing something simple. Guess I will try building and linking it to see what happens. -- Shawn Church sl_church(a)sbcglobal.net

1 1

RE: [Boost-users] configuring boost on MS Visual Studio 6 where t he installation drive isn't C:
by Administrator 05 Feb '04

05 Feb '04

Binaries of bjam are released separately. You can actually download a binary of bjam for nt at the bottom of the Sourceforge download page here: http://sourceforge.net/project/showfiles.php?group_id=7586 Also get the latest version (1.31.0) of boost as it has an easier install stage. The command-line should be: bjam "-sTOOLS=msvc" "-sMSVC_ROOT=D:\Progra~1\Micros~1" You can avoid all that if you execute vcvars32.bat and then do: bjam "-sTOOLS=msvc" That should si -----Original Message----- From: Dernoncourt, Wayne CTR NAVAIR 3184, ,10 [mailto:wayne.dernoncourt@navy.mil] Sent: Thursday, February 05, 2004 10:16 AM To: Boost Users mailing list Subject: RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: (I've been using MS Outlook for years and I still don't like the way it handles quoting like this!) Please pardon the newbieness, these are probably elmentary questions. It turns out the copy of Boost I have didn't have a bjam.exe (I don't know why) so I had to puzzle out how to build that (bad path, etc.) Now trying to figure out how to get Boost to build - done sort of. I don't see how this is going to examine the conflicts with the subset of RogueWave being used by the third party SDK. According to the results from the command "bjam" being executed in the D:\boost-1.30.2 directory: - failed updating 660 targets - skipped 234 targets - updated 260 targets (the actual number has scrolled off screen...) Looking back through the screens, there seem to be CALL "C:\Program Files\Microsoft\Visual Studio...", well that isn't right, it lives on D:, not C:. An earlier email suggested an S setting, so I tried: bjam "VC6_ROOT=D:\Progra~1\Micros~1" and it complains about not having Python (well, it hasn't been installed, we don't need it for this project, though it seems to be very popular) and then it complains about not knowning how to make VC6_ROOT=D:\same stuff. ...found 1 target ...can't find 1 target and it quits.

1 0

RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C:
by Dernoncourt, Wayne CTR NAVAIR 3184, ,10 05 Feb '04

05 Feb '04

Ahhhh, evidently vcvars32.bat wasn't being run to set some envrionment variables. Running this first makes a difference! Now 494 targets failed (there were 660 failing targets), 178 targets were skipped (there were 250). Of the failing targets most seem to be referencing mwcc (metro works c++ compiler?). Still not clear how some of this works. Trying to run the tests we came up with and now the complaining about missing boost/config.hpp... there it is, I can see it<jabbing my finger at the screen>. I'll fool with this some more in the AM... -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Administrator Sent: Wednesday, February 04, 2004 14:54 To: 'Boost Users mailing list' Subject: RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: Wayne, What configure script? Boost requires bjam.exe. If you follow the directions here: http://www.boost.org/more/getting_started.html you should have no problems. I have never had a problem with either MS Visual C++ 6.0 with regards to bjam, nor have I ever used a configure script with Boost. Cygwin is an alternative, but you shouldn't need it if you follow the getting started directions. Dale -----Original Message----- From: Dernoncourt, Wayne CTR NAVAIR 3184, ,10 [mailto:wayne.dernoncourt@navy.mil] Sent: Wednesday, February 04, 2004 9:17 AM To: Boost Users mailing list Subject: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: For a number of reasons we don't have MS Visual Studio installed on the C: drive. We also have another SDK installed that uses part of Rogue Wave. Both libraries try to define min, max and a reverse iterator (there are items, those are the ones we've come across in an afternoon of experimentation). As I understand things, the ./configure script will look for conflicts with other libraries and try to work around them. The ./configure script is a bourne shell script, but there is no obvious way of running that script in Windows. One approach I thought of was to install cygwin to run the script, but that would have to invoke the MS C++ compiler (invoking a Windows based tool from inside of a Linux like environment), I'm not sure that would actually work. Are there alternatives that need to be explored? Would the cygwin approach actually work? (we are currently using MS Visual Studio 6 because of requirement of the other SDK) _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Problem using new regex library
by John Eddy 05 Feb '04

05 Feb '04

Hello, I have just downloaded and installed 1.31.0. I am using MS VC7 and am having the following problem: The following code will not compile (whereas it did previously) #include <locale> using namespace std; #include <boost/regex.hpp> int main(int argc, char* argv[]) { return 0; } The error reported is as follows: regbase.hpp(120) : error C2955: 'std::collate' : use of class template requires template argument list The offending line of code is: collate = ::boost::regbase::collate, which is one member of an enumeration. The code looks fine to me so this seems to be a problem with the compiler. Has anyone already dealt with this? Thanks, John

1 0

RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C:
by Dernoncourt, Wayne CTR NAVAIR 3184, ,10 05 Feb '04

05 Feb '04

(I've been using MS Outlook for years and I still don't like the way it handles quoting like this!) Please pardon the newbieness, these are probably elmentary questions. It turns out the copy of Boost I have didn't have a bjam.exe (I don't know why) so I had to puzzle out how to build that (bad path, etc.) Now trying to figure out how to get Boost to build - done sort of. I don't see how this is going to examine the conflicts with the subset of RogueWave being used by the third party SDK. According to the results from the command "bjam" being executed in the D:\boost-1.30.2 directory: - failed updating 660 targets - skipped 234 targets - updated 260 targets (the actual number has scrolled off screen...) Looking back through the screens, there seem to be CALL "C:\Program Files\Microsoft\Visual Studio...", well that isn't right, it lives on D:, not C:. An earlier email suggested an S setting, so I tried: bjam "VC6_ROOT=D:\Progra~1\Micros~1" and it complains about not having Python (well, it hasn't been installed, we don't need it for this project, though it seems to be very popular) and then it complains about not knowning how to make VC6_ROOT=D:\same stuff. ...found 1 target ...can't find 1 target and it quits. -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Administrator Sent: Wednesday, February 04, 2004 14:54 To: 'Boost Users mailing list' Subject: RE: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: Wayne, What configure script? Boost requires bjam.exe. If you follow the directions here: http://www.boost.org/more/getting_started.html you should have no problems. I have never had a problem with either MS Visual C++ 6.0 with regards to bjam, nor have I ever used a configure script with Boost. Cygwin is an alternative, but you shouldn't need it if you follow the getting started directions. Dale -----Original Message----- From: Dernoncourt, Wayne CTR NAVAIR 3184, ,10 [mailto:wayne.dernoncourt@navy.mil] Sent: Wednesday, February 04, 2004 9:17 AM To: Boost Users mailing list Subject: [Boost-users] configuring boost on MS Visual Studio 6 where the installation drive isn't C: For a number of reasons we don't have MS Visual Studio installed on the C: drive. We also have another SDK installed that uses part of Rogue Wave. Both libraries try to define min, max and a reverse iterator (there are items, those are the ones we've come across in an afternoon of experimentation). As I understand things, the ./configure script will look for conflicts with other libraries and try to work around them. The ./configure script is a bourne shell script, but there is no obvious way of running that script in Windows. One approach I thought of was to install cygwin to run the script, but that would have to invoke the MS C++ compiler (invoking a Windows based tool from inside of a Linux like environment), I'm not sure that would actually work. Are there alternatives that need to be explored? Would the cygwin approach actually work? (we are currently using MS Visual Studio 6 because of requirement of the other SDK) _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Boost release 1.31.0 is available
by Beman Dawes 05 Feb '04

05 Feb '04

Boost release 1.31.0 is available. See the www.boost.org home page for latest news about what's in the release. Or go right to http://sourceforge.net/project/showfiles.php?group_id=7586 to download. Thanks to everyone who helped with this release. The folks that run the regression tests and review the release candidates get a special pat on the back. Due to compiler updates, three shipping and one soon-to-ship C++ compiler now pass almost all of Boost's regression tests. A year ago, no compilers could do that. --Beman

3 3

Problems with boost build with latest CVS head.
by Jeff Holle 05 Feb '04

05 Feb '04

I updated my CVS head of boost at Wed Feb 4 13:17:44 PST 2004. I am using gcc version 3.3. I've run into 2 types of problems which I have not experienced before. 1. There is some diff trible in boost/tools/build/v1/gcc-tools.jam starting at line 61. I solved it by commenting out three lines. 2. Compiler errors with boost/libs/date_time/src/gregorian/greg_month.cpp at line 18. Since I'm not using this part of boost, I haven't bothered fixing it. An example of the errors is: /boost/boost/date_time/date_parsing.hpp: In function ` date_type boost::date_time::parse_date(const std::string&, int)': /boost/boost/date_time/date_parsing.hpp:100: error: parse error before `>' token

3 3

Rationale on explicit shared_ptr constructor
by Aaron W. LaFramboise 05 Feb '04

05 Feb '04

Hi, (I can't beleive this wouldn't have been discussed already, but I haven't been able to find an answer in my searches [Google's search results into boost's web maillist seem to be incoherent.].) I recently converted a portion of a medium-sized project from loki::Smart_Ptr to boost::shared_ptr (primarily for weak_ptr support), and almost everything worked out of the box, except: boost: template<class Y> explicit shared_ptr <#constructors>(Y * p); loki: SmartPtr(const StoredType& p) In other words, code like this stopped working: some_smart_ptr<int> my_function() { return new int; // error: conversion from `int*' to non-scalar type `boost::shared_ptr<int>' // requested } Even when I adopt the convention to convert the return value to the smart pointer type such as with "return some_smart_ptr<int>(new int)", returning a null pointer as 'zero' doesn't work: some_smart_ptr<int> my_function() { return some_smart_ptr<int>(0); // error: no matching function for call to // `boost::shared_ptr<int>::shared_ptr(int)' } I've worked around this by simply using "return some_smart_ptr<int>();". However, I feel somewhat strongly that this sort of usage is unnecessarily ugly, and confuses the meaning of the code unnecessarily. More importantly, it causes smart pointers to behave differently from ordinary pointers, which is undesirable, as it requires the user (who may not know or care anything about the smart pointer, or even know that it is one, depending on a module's implementation and documentation) to have to learn and use and debug additional semantics. So my question follows. I understand that there are very good reasons for disallowing automatic conversion from a smart pointer, but why disallow automatic conversion to the smart pointer type also? If there are strong reasons for this, would it be reasonable to document this somewhere in the shared_ptr documentation? If not, is this particular aspect of shared_ptr possibly subject to discussion or change in the future? Thank you for your time, Aaron W. LaFramboise

2 1