Home Dashboard Directory Help
Search

share_ptr by 我爱大葱


Status: 

Closed
 as By Design Help for as By Design


2
0
Sign in
to vote
Type: Bug
ID: 522404
Opened: 12/28/2009 11:01:38 PM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

using namespace std;
using namespace boost;    

typedef shared_ptr<CDataset> DataSetPtr;
typedef shared_ptr<CEditableDataset> EditDataSetPtr;    
Details
Sign in to post a comment.
Posted by Microsoft on 1/7/2010 at 3:58 PM
using-declarations (that's what "using boost::shared_ptr;" is called, while "using namespace boost;" is called a using-directive) are reasonable here, if somewhat verbose.

Stephan T. Lavavej
Visual C++ Libraries Developer
Posted by Rolf Kristensen on 1/7/2010 at 1:31 AM
Guess the correct solution is not to use "using namespace std" and "using namespace boost", but to explicitly include the necessary classes:

using boost::shared_ptr;
using std::string;
using std::vector;
etc.
Posted by Rolf Kristensen on 1/6/2010 at 3:07 AM
We have a rather large project, where we use boost extensively, and we want to convert to VS2010.

The problem is that when having "using namespace std" and "using boost::shared_ptr" in stdafx.h.

When not having specified that one is using the tr1 namespace, then why does the conflict happen ?

Is it possible to tell VS2010 not to include the stuff inside the tr1 namespace ? So we can make the shift from boost to tr1 when we are ready ?
Posted by Microsoft on 1/5/2010 at 12:28 PM
Hi,

Thanks for reporting this issue. I've resolved it as By Design, because VC10 has implemented most of the C++0x Standard Library. C++0x/VC10 provides std::shared_ptr (and std::make_shared<T>(), etc.) in <memory>. Because the Standard headers include each other in unspecified ways, including <iostream> may or may not drag in <memory> and therefore may or may not make std::shared_ptr visible. When both std::shared_ptr and boost::shared_ptr are visible, and using-directives for both namespace std and namespace boost are in scope, you need to explicitly qualify std::shared_ptr or boost::shared_ptr in order to disambiguate which one you want.

(Error messages talk about std::tr1::shared_ptr because of an implementation artifact. For backwards compatibility, we currently provide both std::shared_ptr and std::tr1::shared_ptr. Currently, we actually define shared_ptr in std::tr1 and lift it into namespace std with a using-declaration. Thus, shared_ptr appears to live in std, but its true name is std::tr1::shared_ptr. In the future, for increased conformance, we'll reverse this, and in the far future we might remove tr1 completely.)

Essentially, Boost is a victim of its own success here.

If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer
Posted by Microsoft on 1/3/2010 at 10:31 PM
We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Thanks!
Posted by Microsoft on 12/30/2009 at 3:44 AM
Hi,

To help us better understand the scenario,could you please attach a zipped project file to help us reproduce this issue?

Thank you,
Visual Studio Product Team.
Posted by Microsoft on 12/30/2009 at 3:15 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.