Function templates

LegacyForum

Hello,

I am having difficulty matching code patterns involving function templates using the rule wizard.

It seems that context a(b) does not work when "a" is function template.

Here is the template:

template <typename object>
void ptr_remove(const object*& to_remove)
{
if(to_remove != NULL)
delete to_remove;
to_remove = NULL;
}

Here is the call I am trying to match:

void A::~A(void)
{
ptr_remove(m_foo);
}

In this case context a(b) does not match. If I replace ptr_remove with a regular function that is specific to the pointer type in question the match works as expected.


Any comments on this topic would be greatly appreciated.

Thanks,

Steve

LegacyForum

Hello swickham

C++Test uses the Edison Desing Group ( http://www.edg.com) parser, which requires template instantiantion in order to recoginize the data within the template function. Therfore in order to
for C++Test to report the coding violation. Your source code must have have the body of template function explicitly specialized in the source code, and the template function instantiation used somewhere in the code.

LegacyForum

Hi toris,

Thanks for your reply. I have tried the explicit specialization as you suggested. It doesn't seem to work though. To help illustrate the problem I have created a simple test scenario with a header, cpp, and rule file. The rule is simple customization of ellemtel rule 58-2 and is attached to this post. I have also experimented with the EDG instantiation #pragma directives with no success.


Header and cpp are as follows:

Header:
======

#if !defined(TEST_H)
#define TEST_H

class Test
{

public:

Test(void);
~Test(void);

private :

int* m_foo;
int* m_bar;
int* m_moo;

};

// basic template
template <typename T>
void ptr_remove_template(T*& to_remove)
{
if(to_remove != NULL)
{
delete to_remove;
to_remove = NULL;
}
}

// explicit specialization
template<> void ptr_remove_template(int*& to_remove)
{
if(to_remove != 0)
{
delete to_remove;
to_remove = 0;
}
}

// regular function
void ptr_remove_int(int*& to_remove)
{
if(to_remove != 0)
{
delete to_remove;
to_remove = 0;
}
}

#endif


cpp:
===

#include "Test.h"

Test::Test(void)
: m_foo(0),
m_bar(0)
{
m_foo = new int(5);
m_bar = new int(10);
m_moo = new int(15);
}

Test::~Test(void)
{
delete m_foo; // rule detects this
ptr_remove_int(m_bar); // rule detects this
ptr_remove_template(m_bar); // rule doesn't detect this
}

LegacyForum

Hello swickham

Could you try the following example, and let me know if C++Test reports the ellemtel_rec-58_2 coding violation, when the object is initialize in the source code.

---------------cut---------------
//try.h

template <class T>
class A
{
public:
A();
~A();

private:
T *a;

};


template <class T>
A<T>::A()
{

a = new int(); // should report ellemtel_rec-58_2 coding violation
}

template <class T>
A<T>::~A()
{

}
----------------------- cut -----------------------------------
// try.cpp

#include "try.h"

void foo()
{
A<int> aObject; // Instantiate the object and C++Test will report the violation
}
-------------cut-------------

LegacyForum

Hi toris,

Yes - the rule is triggered in the case you have outlined below.

Please forgive me if I am being slow, but this case involves a class template, while the original problem involves a function template.

Thanks for your continued help ...

Steve

LegacyForum

Hello swickham

The ellemtel_58_2 rule reports a coding violation for memory was allocated in the constructor, but was not deleted in the destructor.

1. The example you placed on the forum allocates , memory for m_foo, m_bar, and m_moo in the constructor.

2. In the destructor you deallocate the memory for m_foo, which leaves m_bar and m_moo not deallocated.

3. Without template instantiation C++Test reports m_moo was not deallocated


4. With template instantiation C++Test reports m_bar, and m_moo not deallocated.


Add the following function to test.cpp to instantiate the template object
-----------------------------------------------------
void foo()
{
Test *t = new Test();
}

------------------------------------------------------

LegacyForum

Thanks toris - this seems to have cleared things up.