This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6000 7.4.5 auto_ptr re-assignment error: no operator "="

I'm porting a test platform to the C6000 simulator, using the latest toolchain I could find.  The test framework uses auto_ptr extensively, and reassigns pointers, which causes a compile time error.  I know that auto_ptr has changed a bit over time, but to my limited knowledge this should really really be okay. The code boils down to:

#include <memory>
struct A
{    int a;
};

std::auto_ptr<A> CreateA(void)
{
    return std::auto_ptr<A>(new A);
}

void test(void)
{
    std::auto_ptr<A> aPtr;
    aPtr = CreateA();
}

Which unfortunately results in:

blah>C:/tools/ti/ccsv4/tools/compiler/c6000_7.4.5/bin/cl6x --include_path="C:/tools/ti/ccsv4/tools/compiler/c6000_7.4.5/include" test.cpp
"test.cpp", line 17: error: no operator "=" matches these operands
            operand types are: std::auto_ptr<A> = std::auto_ptr<A>

  • Hello!

    Huh...And if thus:

    #include <memory>


    struct A
    {    int a;
    };

    void test(void)

    {

        std::auto_ptr<A> aPtr;
        aPtr = std::auto_ptr<A> (new A);
    }

    Did warning appear at this case also? http://www.cplusplus.com/reference/memory/auto_ptr/

    Regards,

    Igor

  • Yes, it occurs in that instance as well.  Also, just to note it is an error, not warning.

    And yes, I'm familiar with auto_ptrs, and use them a lot, however mostly with GCC and MSVC, and I would note that my usage is an extremely common pattern - as a return value from a factory class/function.

    Hopefully TI can repro the issue since for me it was very easy to do so.

  • Hi Peter!

    Yes, I see, "warning" was my typo.

    Peter Maresh said:

    and use them a lot, however mostly with GCC and MSVC

    But it is not fact that TI C/C++ compiler supports this. At least in TI wiki an information is absent. For example I know that some GCC language constructions are not supported also.  Anyway have to wait for comments of TI employees.

    Good luck,

    Igor

  • Cool, thanks, I would point out that auto_ptr is part of the STL standard, and must behave in a standard way, and TI claims compliance to the 98 version of the spec.  The manual (SPRU187 (U and others)) in 6.2 does list exceptions to the implementation of their implementation, there is nothing that seems relevant to auto_ptr.

  • Hi,

    Since the function return a temporary and a temorary can be bind only to a const reference, the compiler should autopatically convert it to auto_ptr_ref and use the operator

      auto_ptr& operator= (auto_ptr_ref<X> r)

    While it seem to me that the C6000 TI library defines only the operator:

        auto_ptr<X>& operator=(auto_ptr_ref<X& r)    //TI bug or non C++ std compliance?

    That is another reference to non-const object and again cannot be bind to a temporary.

    Note that auot_ptr_ref  "is an instrumental class to allow certain conversions that allow auto_ptr objects to be passed to and returned from functions" (from www.cplusplus.com)

  • I think this is a bug in the implementation of autoptr.  I submitted SDSCM00048282 to the SDOWP system to have this looked at.  Feel free to follow it with SDOWP link below in my signature.

    One possible workaround is to use the implementation of autoptr from the book The C++ Standard Library by Nicolas Josuttis.  You can download most of the example code in the book from here.  The autoptr implementation is described on pages 56-58.  I verified that your example builds clean with this autoptr implementation.  This code has not been tested with the TI compiler, so I cannot offer any guarantee.

    Thanks and regards,

    -George

  • Thanks George and Igor.

    I was also able to verify that Igor was correct in noticing that for the Colvin-Gibbons trick to work, the auto_ptr_ref must have a pass by value argument, not pass by reference.  Removing the ampersand causes it to work.  I'm a little worried that although it may work in my example, that due to some subtlety in the compiler itself it may not work in all situations that it is required to work.  AFAIK, the header files are Dinkumware, and those have been used all over the industry and it seems odd that such a basic part of the STL would not work and not be noticed to have not worked in the last 10 years or so that the C6000 has supported C++/STL. Maybe the header was deliberately changed to cause this error to be issued because the compiler may not do the right thing in some corner cases.  Unfortunately this is where my knowledge of the "trick" and auto_ptr_ref is not sufficient to create good test cases.

    So, I'm interested to track the bug and try to get some assurance that a fixed auto_ptr (or alternate) will work in all contexts with the C6000 C++ compiler.

    Thanks!