<![CDATA[MISRA Discussion Forums - 6.14 Templates (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:12:49 +0000 MyBB <![CDATA[Rul1 14-7-1 and explicit class instantiation]]> https://forum.misra.org.uk/showthread.php?tid=1658 Wed, 30 Aug 2023 06:58:13 +0000 mstaron]]> https://forum.misra.org.uk/showthread.php?tid=1658 In this case member functions are instantiated accordingly to the C++ standard:

Quote:8 An explicit instantiation that names a class template specialization is also an explicit instantiation of the
same kind (declaration or definition) of each of its members (not including members inherited from base
classes and members that are templates) that has not been previously explicitly specialized in the translation
unit containing the explicit instantiation, except as described below. [ Note: In addition, it will typically be
an explicit instantiation of certain implementation-dependent data about the class. —end note ]
9 An explicit instantiation definition that names a class template specialization explicitly instantiates the class
template specialization and is an explicit instantiation definition of only those members that have been
defined at the point of instantiation.
but these functions are never used.

Example:

Code:
template <typename T>
class Temp {
    public:
    void f1(){}  // Compliant?
    void f2(){}  // Compliant?
};

template class Temp<int>;
]]> In this case member functions are instantiated accordingly to the C++ standard:

Quote:8 An explicit instantiation that names a class template specialization is also an explicit instantiation of the
same kind (declaration or definition) of each of its members (not including members inherited from base
classes and members that are templates) that has not been previously explicitly specialized in the translation
unit containing the explicit instantiation, except as described below. [ Note: In addition, it will typically be
an explicit instantiation of certain implementation-dependent data about the class. —end note ]
9 An explicit instantiation definition that names a class template specialization explicitly instantiates the class
template specialization and is an explicit instantiation definition of only those members that have been
defined at the point of instantiation.
but these functions are never used.

Example:

Code:
template <typename T>
class Temp {
    public:
    void f1(){}  // Compliant?
    void f2(){}  // Compliant?
};

template class Temp<int>;
]]> <![CDATA[Rule 14-7-1 and templates that must be specialized]]> https://forum.misra.org.uk/showthread.php?tid=1619 Fri, 29 Apr 2022 22:25:57 +0000 chgros]]> https://forum.misra.org.uk/showthread.php?tid=1619
Code:
template<bool b> SomeClass;

template <> SomeClass<true> {
  void foo();
};
SomeClass<true> s;

We report a 14-7-1 defect, as non-specialized SomeClass is never instantiated.
They're complaining it's a false positive. Could we get a ruling? Arguably the explicit specialization and the non-specialization are different classes, and to be compliant both should be instantiated. On the other hand, this might be a reasonable thing to do if e.g. the goal is to prevent the code from working with <false> (note: I'm only guessing at the goal. The example from the customer doesn't go much further than this)
Do you have any guidance?]]>
Code:
template<bool b> SomeClass;

template <> SomeClass<true> {
  void foo();
};
SomeClass<true> s;

We report a 14-7-1 defect, as non-specialized SomeClass is never instantiated.
They're complaining it's a false positive. Could we get a ruling? Arguably the explicit specialization and the non-specialization are different classes, and to be compliant both should be instantiated. On the other hand, this might be a reasonable thing to do if e.g. the goal is to prevent the code from working with <false> (note: I'm only guessing at the goal. The example from the customer doesn't go much further than this)
Do you have any guidance?]]> <![CDATA[Rule 14–7–3 Example errata?]]> https://forum.misra.org.uk/showthread.php?tid=939 Thu, 07 Feb 2013 23:58:10 +0000 minhyuk]]> https://forum.misra.org.uk/showthread.php?tid=939
a function template specialization for good_tmp1 violated ODR in tmp1.cc.
Code:
// tmp1.h
template  void good_tmp1 ( ) { }

// tmp1.cc
#include "tmp1.h"
template  void good_tmp1 ( ) { }

I think function template specialization must be forward declaration in header file.
any reason for that?

Best Regards,
Minhyuk Kwon@Suresoft technologies Incs.]]>
a function template specialization for good_tmp1 violated ODR in tmp1.cc.
Code:
// tmp1.h
template  void good_tmp1 ( ) { }

// tmp1.cc
#include "tmp1.h"
template  void good_tmp1 ( ) { }

I think function template specialization must be forward declaration in header file.
any reason for that?

Best Regards,
Minhyuk Kwon@Suresoft technologies Incs.]]> <![CDATA[Problems with Rule 14–6–2]]> https://forum.misra.org.uk/showthread.php?tid=549 Wed, 09 Jul 2008 20:30:23 +0000 James Widman]]> https://forum.misra.org.uk/showthread.php?tid=549
The second example in 14–6–2 is:

Code:
template  
void f ( T const & t )
{
   t == t;                       // Non-compliant - Calls NS::operator==
                                 // declared after f
   ::operator ==( t, t );        // Compliant - Calls built-in operator==
   ( operator ==  ) ( t, t ); // Compliant - Calls built-in operator==
}

namespace NS
{
   struct A
   {
      operator int32_t ( ) const;
   };
   bool operator== ( A const &, A const & );
}

int main ( )
{
   NS::A a;
   f ( a );
}
One problem is that the expression '::operator==(t,t)' renders the program ill-formed at template definition time (which means that, if your compiler conforms to ISO C++ 2003, it will issue an error at template definition time and refuse to generate code). This is given by ISO C++ in 14.6 temp.res, which contains this bit of normative text:
Quote:If a name does not depend on a template-parameter (as defined in 14.6.2), a declaration (or set of declarations) for that name shall be in scope at the point where the name appears in the template definition; the name is bound to the declaration (or declarations) found at that point and this binding is not affected by declarations that are visible at the point of instantiation.
Because of the way 'operator==' is written, we know that it is not a dependent name. So unqualified name lookup searches for 'operator==' and finds nothing because there is no declaration of that operator before f (either in this example or in the previous example). So the program is ill-formed (diagnostic required).

Likewise, 'operator==' would also render the program ill-formed (if it were not ill-formed already) because there is no operator== template in scope, so the ']]>
The second example in 14–6–2 is:

Code:
template  
void f ( T const & t )
{
   t == t;                       // Non-compliant - Calls NS::operator==
                                 // declared after f
   ::operator ==( t, t );        // Compliant - Calls built-in operator==
   ( operator ==  ) ( t, t ); // Compliant - Calls built-in operator==
}

namespace NS
{
   struct A
   {
      operator int32_t ( ) const;
   };
   bool operator== ( A const &, A const & );
}

int main ( )
{
   NS::A a;
   f ( a );
}
One problem is that the expression '::operator==(t,t)' renders the program ill-formed at template definition time (which means that, if your compiler conforms to ISO C++ 2003, it will issue an error at template definition time and refuse to generate code). This is given by ISO C++ in 14.6 temp.res, which contains this bit of normative text:
Quote:If a name does not depend on a template-parameter (as defined in 14.6.2), a declaration (or set of declarations) for that name shall be in scope at the point where the name appears in the template definition; the name is bound to the declaration (or declarations) found at that point and this binding is not affected by declarations that are visible at the point of instantiation.
Because of the way 'operator==' is written, we know that it is not a dependent name. So unqualified name lookup searches for 'operator==' and finds nothing because there is no declaration of that operator before f (either in this example or in the previous example). So the program is ill-formed (diagnostic required).

Likewise, 'operator==' would also render the program ill-formed (if it were not ill-formed already) because there is no operator== template in scope, so the ']]> <![CDATA[Rule 14–8–1 and dissimilar overloaded templates]]> https://forum.misra.org.uk/showthread.php?tid=545 Thu, 03 Jul 2008 23:15:48 +0000 James Widman]]> https://forum.misra.org.uk/showthread.php?tid=545
I suspect that the net cast by rule 14–8–1 is too wide. For example, I don't think it's helpful to label the following as "non-compliant":

Code:
template  void f ( T );  // #1
template  void f ( T*, T ); // #2

template  void f ( int32_t* ); // non-compliant with 14–8–1

In this case, the specialization of #1 cannot get you into trouble.

In the actual example given for 14–8–1, it is helpful to claim that the specialization is suspect because there is another template that would have been a better match if only the explicit template argument list had not been given, and a user (especially someone writing a call to the template) may not have an understanding of the type deduction rules sufficient to know which template would be selected when there are multiple matches and only one match is selected by partial ordering.

But who, without the assistance of medication, would not just assume that #1 (in the example above) is being specialized in the explicit-specialization? Likewise, who, in the absence of default arguments and in the absence of any other overload, would not just assume that #1 would be called when the call expression contains only one argument?

I recommend changing the wording of the rule to:

Quote:An overloaded function template shall not be explicitly
specialized if, in the absence of an explicit
template-argument-list, at least one template other than
the selected template would succeed at type deduction against
the function type given by the explicit specialization.
]]>
I suspect that the net cast by rule 14–8–1 is too wide. For example, I don't think it's helpful to label the following as "non-compliant":

Code:
template  void f ( T );  // #1
template  void f ( T*, T ); // #2

template  void f ( int32_t* ); // non-compliant with 14–8–1

In this case, the specialization of #1 cannot get you into trouble.

In the actual example given for 14–8–1, it is helpful to claim that the specialization is suspect because there is another template that would have been a better match if only the explicit template argument list had not been given, and a user (especially someone writing a call to the template) may not have an understanding of the type deduction rules sufficient to know which template would be selected when there are multiple matches and only one match is selected by partial ordering.

But who, without the assistance of medication, would not just assume that #1 (in the example above) is being specialized in the explicit-specialization? Likewise, who, in the absence of default arguments and in the absence of any other overload, would not just assume that #1 would be called when the call expression contains only one argument?

I recommend changing the wording of the rule to:

Quote:An overloaded function template shall not be explicitly
specialized if, in the absence of an explicit
template-argument-list, at least one template other than
the selected template would succeed at type deduction against
the function type given by the explicit specialization.
]]> <![CDATA[Rule 14–6–1 and injected-class-names]]> https://forum.misra.org.uk/showthread.php?tid=544 Thu, 03 Jul 2008 16:56:26 +0000 James Widman]]> https://forum.misra.org.uk/showthread.php?tid=544
Rule 14–6–1 says:

"In a class template with a dependent base, any name
that may be found in that dependent base shall be
referred to using a qualified-id or this->"

But then the example code contains this line:
Code:
typename B::TYPE t2 = 0; // Compliant - explicit use base TYPE
But I don't think that's correct, because although TYPE is qualified, B is not. I think this line should be moved into A::f1() and commented with "Non-compliant: B is unqualified". And add the line:
Code:
typename ::B::TYPE t2 = 0; // Compliant - explicit use of B and of TYPE.
...to f2().

Here's an example where it makes a difference:
Code:
template  
struct B  {
    static void j();
};

namespace N {
    template  
        struct B {
            static void j();
        };

}

template  
struct A : public N::B {
    static void f1 ( ) {
        A::template B::j(); // compliant
        A::B::j(); // compliant
    }
    static void f2 ( ) {
        B::j(); // non-compliant
    }
};

void h() {
    A::f1(); // calls ::N::B::j() twice
    A::f2(); // calls ::B::j() once
}
]]>
Rule 14–6–1 says:

"In a class template with a dependent base, any name
that may be found in that dependent base shall be
referred to using a qualified-id or this->"

But then the example code contains this line:
Code:
typename B::TYPE t2 = 0; // Compliant - explicit use base TYPE
But I don't think that's correct, because although TYPE is qualified, B is not. I think this line should be moved into A::f1() and commented with "Non-compliant: B is unqualified". And add the line:
Code:
typename ::B::TYPE t2 = 0; // Compliant - explicit use of B and of TYPE.
...to f2().

Here's an example where it makes a difference:
Code:
template  
struct B  {
    static void j();
};

namespace N {
    template  
        struct B {
            static void j();
        };

}

template  
struct A : public N::B {
    static void f1 ( ) {
        A::template B::j(); // compliant
        A::B::j(); // compliant
    }
    static void f2 ( ) {
        B::j(); // non-compliant
    }
};

void h() {
    A::f1(); // calls ::N::B::j() twice
    A::f2(); // calls ::B::j() once
}
]]>