Similar Threads
1. auto_ptr assignment crash with VC language extensions
2. auto_ptr assignment compile error
Hello everyone,
I posted the code and related compile error below. My analysis below,
1. I think the reason of compile error is, the copy constructor of Goo
accepts const reference as input parameter, so the pf member of input
parameter is also treated const?
2. And since auto_ptr does not have a copy constructor which accepts const
reference auto_ptr as input parameter, the compile error occurs.
My analysis (1) and (2) are both correct?
What makes me confused is it seems the compile error message does not
reflect my analysis (1) and (2) above. Any ideas?
[Code]
#include <memory>
using namespace std;
// Foo is Pimpl class for Goo, suppose.
class Foo {
};
class Goo {
public:
auto_ptr<Foo> pf;
Goo (const Goo& input)
{
this -> pf = input.pf;
}
};
[/Code]
1>d:\visual studio 2008\projects\test0330\test0330\main.cpp(18) : error
C2679: binary '=' : no operator found which takes a right-hand operand of
type 'const std::auto_ptr<_Ty>' (or there is no acceptable conversion)
1> with
1> [
1> _Ty=Foo
1> ]
1> d:\program files\microsoft visual studio
9.0\vc\include\memory(689): could be 'std::auto_ptr<_Ty>
&std::auto_ptr<_Ty>::operator =<Foo>(std::auto_ptr<_Ty> &) throw()'
1> with
1> [
1> _Ty=Foo
1> ]
1> d:\program files\microsoft visual studio
9.0\vc\include\memory(701): or 'std::auto_ptr<_Ty>
&std::auto_ptr<_Ty>::operator =(std::auto_ptr<_Ty> &) throw()'
1> with
1> [
1> _Ty=Foo
1> ]
1> d:\program files\microsoft visual studio
9.0\vc\include\memory(707): or 'std::auto_ptr<_Ty>
&std::auto_ptr<_Ty>::operator =(std::auto_ptr_ref<_Ty>) throw()'
1> with
1> [
1> _Ty=Foo
1> ]
1> while trying to match the argument list '(std::auto_ptr<_Ty>,
const std::auto_ptr<_Ty>)'
1> with
1> [
1> _Ty=Foo
1> ]
thanks in advance,
George
3. vc8.0 crash while compiling boost-1.33.1 serialization library with /analyze
4. GetControlFlags() crashing in VC8 compiled code
Hi,
I am creating an OCX control and I am using GetControlFlags() in my
code. Following is the code snippet.
DWORD MyControl::GetControlFlags()
{
DWORD dwFlags = COleControl::GetControlFlags();
dwFlags |= noFlickerActivate;
dwFlags |= canOptimizeDraw;
return dwFlags;
}
I have created a test application to create this control using
CAxWindow::CreateControl()
When I compile my OCX control code with VC6 compiler, test application
works fine(means control is being created properly).
But when I compile OCX control with VC8 compiler, test application
crashes with the following exception.
Unhandled exception at 0x7833783e (mfc80u.dll) in test.exe:
0xC0000005: Access violation reading location 0x00000020.
Now, if I comment out this function call MyControl::GetControlFlags(),
then everything goes fine with VC8 compiled code also.
Can anybody suggest if there is some change in GetControlFlags() which
needs to be incorporated before compiling with VC8 compiler or I am
missing something?
Thanks in advance
Varun
5. Assignment of raw pointer to auto_ptr. Is it legal?
6. Pointer problem: compiles but crashes
I've been fooling around with a test class and meanwhile I stumbled on a
pointer problem.
I have two classes, one being nested in the other. I've wrote a method in
the nested class that would set a nested class's member pointer as a
pointer to an instance of the other class. Here is the code:
<code>
template <class tData>
class Foo
{
????// snip
public:
class Bar
{
protected:
Foo<tData> *m_cursor;
public:
//snip
void point_to(Foo<tData> &);
}; ??
};
// snip
template <class tData>
void Foo<tData>::Bar::point_to(Foo<tData> &pointed_to)
{
this->m_cursor = &pointed_to;
}
</code>
This code compiles under GCC without a single error or warning, even with
the -pedantic and -Wall flags.
The problem lies when I run the following test cod:
<code>
int main(int argc, char *argv[])
{
Foo<int> a;
Foo<int>::Bar b;
????
b.point_to( a);
return EXIT_SUCCESS;
}
</code>
That code also compiles withou a single problem. Yet, when I run the test
application, it crashes and the following message pops up:
<shell>
*** glibc detected *** free(): invalid pointer: 0xbfb01a10 ***
/bin/sh: line 1: ?703 Aborted ????????/mytree
Press Enter to continue!
</shell>
I can't see where the problem lies. Not only does the code compile but I
also the class points it's member pointer to an already declared variable.
I can't see what's going wrong in here.
So, can anyone shed some light on this problem?
Thanks in advance
Rui Maciel
--
Running Kubuntu 5.10 with KDE 3.5.1 and proud of it.
jabber: XXXX@XXXXX.COM
7. Never ever use a raw pointer when a smart pointer can do the same job
8. Never ever use a raw pointer when a smart pointer can do the same job
* James Kanze:
> On Aug 13, 5:15 pm, "Hicham Mouline" < XXXX@XXXXX.COM > wrote:
>> ... my colleague says.
>
>> I disagree on the "Never".
>
>> Opinions about this "rule of thumb" welcome.
>
> It's one of the stupidest rules I've heard of. The rule should
> be just the opposite: "never use a smart pointer when a raw
> pointer will do the job".
Here the reader will, IMHO, benefit from considering the context:
* James is one of the few who uses garbage collection in C++.
A typical programmer isn't.
* James is very much aware of where raw pointers "will do the
job", with a sophisticated understanding of what "the job" is.
A typical programmer isn't.
* James typically works with well-designed classes.
A typical programmer relates to classes that aren't that well
designed.
So although James' rule fits James, IMHO it doesn't fit the typical programmer.
For the typical programmer the main problem is to get the programmer to apply
automated and secure lifetime management, at all (smart pointers also solve
other problems, such as automated checking of availability, automated mutually
exclusive access, and so on, but such concerns are lesser issues).
> But even that's stupid, in a
> way---smart pointers and raw pointers are different beasts, and
> generally not interchangeable. Generally, if a smart pointer
> will do the job, a raw pointer can't, and vice versa (unless you
> have some very stupid and useless smart pointers).
That statement relies on a sophisticated understanding of what "do the job" entails.
For a more simple understanding, such as "can be made to (apparently) work",
it's not the case that raw pointers can't do the job of smart pointers.
This follows from simple logic: at any point where a smart pointer would do
something extra, such as updating a reference count, that extra action, or
something equivalent and possibly more efficient, can be done explicitly with a
raw pointer.
Using a raw pointer where a smart pointer would be appropriate is the same as
basic "if" and "goto" being sufficient to express "for", "while", "do", "else"
and conditional operator. It's not impossible. When one considers only an
individual statement or two the "goto" based code is even simpler, because there
are only very simple "if" choices and very simple direct jumps, that's all (of
course at a higher level of abstraction the spaghetti code isn't simple).
And in the same way as with "goto", with a very narrow focus on individual
statements using a raw pointer might seem simpler, because there are only very
simple operations. And in the same way as with "goto", at a higher level of
abstraction, considering what the code accomplishes, the raw pointer based code
isn't simple. For in the same way as "goto", what the raw pointer lacks is (1)
restrictions on what you can do, and (2) automation of various actions.
> In practice, in most application level software (at least in the
> domains I've worked in), most pointers will be raw, because a
> smart pointer would not do the job---at least not correctly.
> But most is not all, and there will almost always be some cases
> where the smart pointer is more appropriate as well.
"most application level software" is IMHO a severe over-generalization.
Cheers,
- Alf