Assigning __FILE__ to a char* gives warning

[allan.mcrae]

As part of a very simple memory leak detector, I am trying to store
the value of __FILE__ in a char*. Since gcc4.2 I get the following
warning...

warning: deprecated conversion from string constant to 'char*'

From what I understand about __FILE__ it returns a const char[]

object. The macro of delete assigns this to a global char* which is
used to track where deletions were made. Something like:

#define delete delete_FILE_ = __FILE__, \
delete_LINE_ = __LINE__, \
delete

Removing the delete_FILE_ = __FILE__ line stops the error. How do I
do this properly?

 

[Daniel T.]

As part of a very simple memory leak detector, I am trying to store
the value of __FILE__ in a char*. Since gcc4.2 I get the following
warning...

warning: deprecated conversion from string constant to 'char*'

From what I understand about __FILE__ it returns a const char[]
object. The macro of delete assigns this to a global char* which is
used to track where deletions were made. How do I do this properly?

Use a const char* instead of a char*.

 

[allan.mcrae]

Thanks, that fixed the problem.

 

[Daniel T.]

As part of a very simple memory leak detector, I am trying to store
the value of __FILE__ in a char*. Since gcc4.2 I get the following
warning...

warning: deprecated conversion from string constant to 'char*'

From what I understand about __FILE__ it returns a const char[]

object. The macro of delete assigns this to a global char* which is
used to track where deletions were made. Something like:

#define delete delete_FILE_ = __FILE__, \
delete_LINE_ = __LINE__, \
delete

Removing the delete_FILE_ = __FILE__ line stops the error. How do I
do this properly?

I have a question about the above... I also have code that redefines new
and delete for leak detection, but I'm not really sure if redefining
keywords like that is appropriate. Is it allowed by the standard?

My code looks something like this:

void* operator new( std::size_t size, const char* fileName, int line );
void* operator new[]( std::size_t size, const char* fileName, int line );

#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW

void operator delete( void* address ) throw();
void operator delete[]( void* address ) throw();

 

[Alf P. Steinbach]

* Daniel T.:

As part of a very simple memory leak detector, I am trying to store
the value of __FILE__ in a char*. Since gcc4.2 I get the following
warning...

warning: deprecated conversion from string constant to 'char*'

From what I understand about __FILE__ it returns a const char[]

object. The macro of delete assigns this to a global char* which is
used to track where deletions were made. Something like:

#define delete delete_FILE_ = __FILE__, \
delete_LINE_ = __LINE__, \
delete

Removing the delete_FILE_ = __FILE__ line stops the error. How do I
do this properly?

I have a question about the above... I also have code that redefines new
and delete for leak detection, but I'm not really sure if redefining
keywords like that is appropriate. Is it allowed by the standard?

Not if you're using any parts of the C++ standard library.

In practice it can also lead to severe problems, and in particular, that
some problems only manifest themselves in a release build.

For example, Microsoft redefined operator delete in their MFC library,
with the result that (keep in mind the Microsoft generally has a very
low or non-existent quality of code) exceptions in constructors would
leak memory in release builds, but not in debug builds...

My code looks something like this:

void* operator new( std::size_t size, const char* fileName, int line );
void* operator new[]( std::size_t size, const char* fileName, int line );

#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW

void operator delete( void* address ) throw();
void operator delete[]( void* address ) throw();

With a standard-conforming compiler this will reproduce Microsoft's
problem with MFC, that is, leaks when constructors throw.

I'll leave you to figure out why.

Bug general advice: don't do use things you don't understand, at the
architecture level where it affects all code.

Instead, use proven techniques, such as smart pointers, and tools, such
as e.g. ValGrind. I've never needed to use it myself, so I don't know
from first-hand experience how effective it is at detecting a sloppy
programmer's mess. But as I understand it, for those who prefer to use
days and weeks to fix up their mess afterwards, plus ditto extra time
for any maintainance, instead of minutes or hours Doing It Right in the
first place, ValGrind & friends are indispensable tools and work OK.

 

[Daniel T.]

My code looks something like this:

void* operator new( std::size_t size, const char* fileName, int line );
void* operator new[]( std::size_t size, const char* fileName, int line );

#define DEBUG_NEW new(__FILE__, __LINE__)
#define new DEBUG_NEW

void operator delete( void* address ) throw();
void operator delete[]( void* address ) throw();

With a standard-conforming compiler this will reproduce Microsoft's
problem with MFC, that is, leaks when constructors throw.

The system I use the above in, doesn't have exceptions (constructors
can't throw) so I haven't had the problem.

As I understand it, I should provide matching delete functions to avoid
the problem you are talking about:

void operator delete( void* address, const char*, int ) throw();
void operator delete[]( void* address, const char*, int ) throw();

Correct?

Bug general advice: don't do use things you don't understand, at the
architecture level where it affects all code.

Instead, use proven techniques, such as smart pointers, and tools, such
as e.g. ValGrind. I've never needed to use it myself, so I don't know
from first-hand experience how effective it is at detecting a sloppy
programmer's mess. But as I understand it, for those who prefer to use
days and weeks to fix up their mess afterwards, plus ditto extra time
for any maintainance, instead of minutes or hours Doing It Right in the
first place, ValGrind & friends are indispensable tools and work OK.

Well, in my case, it's me fixing other peoples messes, but I understand
your point.