Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Assigning __FILE__ to a char* gives warning

Reply
Thread Tools

Assigning __FILE__ to a char* gives warning

 
 
allan.mcrae@gmail.com
Guest
Posts: n/a
 
      07-08-2007
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?

 
Reply With Quote
 
 
 
 
Daniel T.
Guest
Posts: n/a
 
      07-08-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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*.
 
Reply With Quote
 
 
 
 
allan.mcrae@gmail.com
Guest
Posts: n/a
 
      07-08-2007
Thanks, that fixed the problem.

 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      07-08-2007
(E-Mail Removed) 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();
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      07-08-2007
* Daniel T.:
> (E-Mail Removed) 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?


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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      07-08-2007
"Alf P. Steinbach" <(E-Mail Removed)> wrote:

> > 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
no warning for assigning unsigned int to plain int V.Subramanian, India C Programming 5 10-12-2011 07:41 PM
PyQt4.__file__ gives PyQt4/__init__.py as value wgw Python 1 08-15-2009 09:58 PM
__file__ vs __FILE__ klenwell Python 11 11-05-2007 06:50 PM
Assigning methods to objects, and assigning onreadystatechange to an XMLHttpRequest -- an inconsistency? weston Javascript 1 09-22-2006 09:33 AM
Warning on assigning a function-returning-a-pointer-to-arrays I.M. !Knuth C Programming 17 06-30-2006 04:12 AM



Advertisments