auto_ptr problems

[Nick Keighley]

Hi,

I copy pasted this code from one of my projects to another. (I know
it should be a template, but I figure if I can't get the non-template
version there is no point in making things more complicated)

void Symbol_table::insert (const std::string name, const T* type)
{
std::auto_ptr <const T> ap_type (type); // <-- syntax error
here!

// more code...
}

This worked with one value for T but when I changed it. I got a syntax
error

'std::auto_ptr<class T>::auto_ptr<class T>(class T *)' : cannot
convert parameter 1 from 'const class CowlStatement *' to 'class
CowlStatement *'

It looks like type is const but the auto_ptr is expecting a non-const
in its
constructor. But I declared T as const!

 

[lbonafide]

Hi,

I copy pasted this code from one of my projects to another. (I know
it should be a template, but I figure if I can't get the non-template
version there is no point in making things more complicated)

void Symbol_table::insert (const std::string name, const T* type)
{
    std::auto_ptr <const T> ap_type (type);      // <-- syntax error
here!

    // more code...

}

This worked with one value for T but when I changed it. I got a syntax
error

Post the code that works and the code that fails.

 

[Nick Keighley]

On Mar 28, 9:20 am, Nick Keighley <[email protected]>
wrote:



Post the code that works and the code that fails.

rather long I'm afraid

Symbol_table_ok compiles
Symbol_table_fail doesn't

the problem seems to be the declaration of TfailPtr

<code begin>

#ifdef _MSC_VER
// Microsoft compiler
// disable warning: "identifier was truncated to '255' characters in
the debug information"
#pragma warning (disable:4786)
#endif

#include <string>
#include <memory>
#include <map>

class Tok
{
public:
Tok (std::string name)
:name_(name), special_(false)
{}

virtual ~Tok()
{}

private:
std::string name_;
bool special_;
};

class Tfail
{
public:
Tfail ()
{}

virtual ~Tfail ()
{}

virtual void execute (std:stream&) = 0;
};


typedef std::auto_ptr<Tfail> TfailPtr; // <--- removing this
"fixes" the bug

typedef std::map<std::string,const Tok*> Table_ok;

class Symbol_table_ok
{
public:
Symbol_table_ok ();
~Symbol_table_ok ();

void insert (const std::string name, const Tok* type);

private:
Table_ok table_;
};


typedef std::map<std::string,const Tfail*> Table_fail;

class Symbol_table_fail
{
public:
Symbol_table_fail ();
~Symbol_table_fail ();

void insert (const std::string name, const Tfail* type);

private:
Table_fail table_;
};

Symbol_table_ok::Symbol_table_ok():
table_()
{
}

Symbol_table_ok::~Symbol_table_ok()
{
}

void Symbol_table_ok::insert (const std::string name, const Tok* type)
{
std::auto_ptr <const Tok> ap_type (type);}

Symbol_table_fail::Symbol_table_fail():
table_()
{
}

Symbol_table_fail::~Symbol_table_fail()
{
}

void Symbol_table_fail::insert (const std::string name, const Tfail*
type)
{
std::auto_ptr <const Tfail> ap_type (type); // <-- syntax
error here!
}

int main ()
{
Symbol_table_ok symtab_ok;
Symbol_table_fail symtab_fail;
return 0;
}

<code end>

 

[Joe Greer]

(e-mail address removed):

That code compiles fine for me using VS 7.1

joe

 

[brian tyler]

Your code compiles and runs on GCC 4.1.2 However I am pretty sure that
you always need to initialise an auto_ptr via new or another auto_ptr,
eg:

std::auto_ptr <const Tfail> ap_type (new Tfail() );

Since otherwise when the auto_ptr comes to destroy the pointer it is
managing all kinds of bad things could happen.

 

[James Kanze]

Your code compiles and runs on GCC 4.1.2 However I am pretty
sure that you always need to initialise an auto_ptr via new or
another auto_ptr, eg:

std::auto_ptr <const Tfail> ap_type (new Tfail() );

Since otherwise when the auto_ptr comes to destroy the pointer
it is managing all kinds of bad things could happen.

The pointer used to initialize it must point to an object that
was allocated with new, but there's no rule that the new must be
in the initializer expression. Admittedly, however, using a
pointer passed as an argument is an invitation to misuse.

 

[brian tyler]

Yes I was thinking after I made that post that theoretically it would
be "OK" to pass a new'ed pointer to the function, but practically it
must be better to require that the function take an auto_ptr so that
transfer of ownership would be explicit.

Brian.

 

[Nick Keighley]

(e-mail address removed):

That code compiles fine for me using VS 7.1

ditto for VCC 2008

It failed to compile on an older version of VCC.
I can't re-verify this at the moment.
So it looks like a compiler bug on an old
version of VCC.

thanks

 

[Nick Keighley]

Yes I was thinking after I made that post that theoretically it would
be "OK" to pass a new'ed pointer to the function, but practically it
must be better to require that the function take an auto_ptr so that
transfer of ownership would be explicit.

ok. I've still got some bad "C" habbits.
I tend to overuse raw pointers.