Click to See Complete Forum and Search --> : auto_ptr error
Ravips
December 31st, 2003, 02:05 PM
Hi All,
I have the following code fragment with auto_ptr, and am getting an error that I am finding hard to resolve. If anyone of you can help me with this, I'd greately appreciate it. Thanks.
P.S - THIS CODE COMPILES FINE WITH VC98, BUT IS GIVING ERROR IN VC7 !
========
The code fragment is as followes -
LPCSTR szFloat = "FLOAT";
char szFName[16];
LPSTR szpFName;
szpFName = szFName;
...
...
...
std::auto_ptr<FieldCL> afcTemp2(new FieldCL(szpFName, vZoneLink, OM_CREATE));
if (!afcTemp2->IsValid())
{
return false;
}
lafcZLSizeField.push_back(afcTemp2);
// where FieldCL is a local class
...
...
...
====================
and I am getting the following error -
-------
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\list(34) : error C2558: class 'std::auto_ptr<_Ty>' : no copy constructor available or copy constructor is declared 'explicit'
with
[
_Ty=FieldCL
]
...
...
c:\MRGNETZN.CPP(314) : see reference to class template instantiation 'std::list<_Ty>' being compiled
with
[
_Ty=std::auto_ptr<FieldCL>
]
====================
I tried to cast it to the exact type it is expecting, but that didn't work. Can you please tell what's the solution to this error. Thanks a lot.
- Ravi.
galathaea
January 1st, 2004, 01:45 PM
I really have no idea how this could ever compile. You should have
std::auto_ptr< FieldCL > afcTemp2(new FieldCL(szpFName, vZoneLink,
OM_CREATE));
because you need to tell the auto_ptr class what type to hold. This is probably why you get the errors on missing type, but I would expect a different error about missing parameters or something.
I was also a bit confused about your mention of FieldCL being a local class. If you mean the class is defined inside function scope, then this is another error, since template parameters are not allowed to be instantiated on types of function scope. The standard disallows that type of usage.
Ravips
January 2nd, 2004, 11:54 AM
Thanks Galathea for your reply. Actually, you are right, it should have been -
std::auto_ptr< FieldCL > afcTemp2(new FieldCL(szpFName, vZoneLink,
OM_CREATE));
, but it was my typo.
About FieldCL class, I meant its local to the dll that this is in, not local to the function. I should have been more clear on what I said. Sorry for the confusion, and thanks. Can you please tell me now what am I doing wrong ?.
galathaea
January 2nd, 2004, 08:05 PM
I'm sorry, but somehow I had completely skipped over the actual problem after seeing the potential problems I mentioned in the first post. Now I see that you are using an auto_ptr in a container (std::list) which is a no-no. The auto_ptr cannot assign or copy from anonymous instances because of their special non-const copy ctor / assignment operator=. And unfortunately, those are required by the standard containers because they require true copy semantics as opposed to the move semantics the auto_ptr implements.
A solution can be found over at www.boost.org with their shared_ptr smart pointer. This is pretty much what will be found in the standard library here once the library update completes the standardisation process and vendors have updated their products, but its available for free from the above site now and is very useful.
Ravips
January 7th, 2004, 10:36 AM
Thanks a lot for your reply. I apologize about the delay in replying to your post, since I was taken away to deal with another problem, but now I am back to dealing with this problem again.
After reading your post, and discussing with my colleague, thought "auto_ptr_ref" probably could be used. By wrapping auto_ptr inside a auto_ptr_ref, we made the following changes to the code -
Existing declarations std::list<std::auto_ptr<FieldCL> > are changed to
std::list< std::auto_ptr_ref <std::auto_ptr<FieldCL> > >
The compiler is now not complaining and code is building fine. But is there any problems doing it this way. Please let me know. I truly appreciate your response. Thanks a lot.
Ravi
Rakeshsoni
June 8th, 2005, 07:04 AM
Hi guys,
I am facing quite similar kind of problem with the following code and get the same error with VC++ .NET
auto_ptr< int > AInt;
vector< auto_ptr< int > > vAInt;
vAInt.push_back(AInt);
Can you people shed light on this?
Andreas Masur
June 8th, 2005, 07:11 AM
Hi guys,
I am facing quite similar kind of problem with the following code and get the same error with VC++ .NET
auto_ptr< int > AInt;
vector< auto_ptr< int > > vAInt;
vAInt.push_back(AInt);
Can you people shed light on this?
Well...it is pretty simple...never use the standard 'auto_ptr' within a container since it does not fulfill the requirements for the container....
Rakeshsoni
June 8th, 2005, 08:00 AM
Hi again,
I have found a workaround for this compiler error and that is:
auto_ptr< int > AInt;
vector< auto_ptr< int > > vAInt;
vAInt[vAInt.size() + 0] = AInt;
This suppresses the compiler from making any further noise but i am not very sure of the implications of this.
Any comments?
Andreas Masur
June 8th, 2005, 01:45 PM
I have found a workaround for this compiler error and that is:
auto_ptr< int > AInt;
vector< auto_ptr< int > > vAInt;
vAInt[vAInt.size() + 0] = AInt;
This suppresses the compiler from making any further noise but i am not very sure of the implications of this.
Did you ever try to run this code? This is simply undefined behaviour... ;)
Bottom line is still that you cannot use the standard 'auto_ptr' within a container...from the ISO C++ standard:
The auto_ptr provides a semantics of strict ownership. An auto_ptr owns the object it holds a pointer to. Copying an auto_ptr copies the pointer and transfers ownership to the destination. If more than one auto_ptr owns the same object at the same time the behavior of the program is undefined.
[Note: The uses of auto_ptr include providing temporary exception-safety for dynamically allocated memory, passing ownership of dynamically allocated memory to a function, and returning dynamicallyallocated memory from a function. auto_ptr does not meet the CopyConstructible and Assignable requirements for Standard Library container elements and thus instantiating a Standard Library container with an auto_ptr results in undefined behavior. —end note]
The Boost library (http://www.boost.org) provides an 'auto_ptr' which actually can be used within containers...
Ravips
June 13th, 2005, 04:53 PM
Hi RakeshSoni, like previously suggested (last year), I used the Boost libraries for this, and have not had problems since. Boost team comprises of people who "make" C++ standards, and its very solid from whatever I've heard of. So, you should be fine using their free libraries.
- Ravi.
codeguru.com
Copyright WebMediaBrands Inc., All Rights Reserved.