Assigning __FILE__ to a char* gives warning

Discussion in 'C++' started by allan.mcrae@gmail.com, Jul 8, 2007.

  1. Guest

    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, 2007
    #1
    1. Advertising

  2. Daniel T. Guest

    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*.
     
    Daniel T., Jul 8, 2007
    #2
    1. Advertising

  3. Guest

    Thanks, that fixed the problem.
     
    , Jul 8, 2007
    #3
  4. Daniel T. Guest

    Redefining keywords? (was: Assigning __FILE__ to a char* gives warning)

    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();
     
    Daniel T., Jul 8, 2007
    #4
  5. Re: Redefining keywords?

    * Daniel T.:
    > 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?
     
    Alf P. Steinbach, Jul 8, 2007
    #5
  6. Daniel T. Guest

    Re: Redefining keywords?

    "Alf P. Steinbach" <> 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.
     
    Daniel T., Jul 8, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. lovecreatesbeauty
    Replies:
    1
    Views:
    1,057
    Ian Collins
    May 9, 2006
  2. Eugene Rice

    char as array index gives warning in gcc

    Eugene Rice, Oct 21, 2006, in forum: C Programming
    Replies:
    13
    Views:
    758
    Dave Thompson
    Nov 6, 2006
  3. Peithon

    assigning const char* to char*

    Peithon, Jun 1, 2007, in forum: C Programming
    Replies:
    6
    Views:
    3,483
    Keith Thompson
    Jun 1, 2007
  4. klenwell

    __file__ vs __FILE__

    klenwell, Nov 3, 2007, in forum: Python
    Replies:
    11
    Views:
    928
    Matimus
    Nov 5, 2007
  5. wgw
    Replies:
    1
    Views:
    464
Loading...

Share This Page