By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,551 Members | 2,710 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,551 IT Pros & Developers. It's quick & easy.

Assigning __FILE__ to a char* gives warning

P: n/a
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?

Jul 8 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
al*********@gmail.com wrote:
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*.
Jul 8 '07 #2

P: n/a
Thanks, that fixed the problem.

Jul 8 '07 #3

P: n/a
al*********@gmail.com wrote:
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();
Jul 8 '07 #4

P: n/a
"Alf P. Steinbach" <al***@start.nowrote:
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.
Jul 8 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.