[
https://issues.apache.org/jira/browse/XALANC-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061753#comment-13061753
]
Steven J. Hathaway edited comment on XALANC-570 at 7/8/11 7:20 AM:
-------------------------------------------------------------------
Compiler Warnings JIRA XALANC-570
---------------------------------
Adding "return" to the template operator() functions is NOT TO BE DONE!
See: PROOF-OF-CORRECTNESS ANALYSIS
If you examine the content of (xalanc/Include/STLHelper.hpp)
you will notice that inside the template<argtype, void>
argument_type = (argtype)
result_type = void
Some C++ compilers get confused when a void type gets renamed.
Therefore, the only code fix to resolve the compiler warnings
is to replace "result_type" with "void" in the appropriate places
in the code.
Line 127
void
operator()(argument_type thePointer) const
{
makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
}
Line 245
void
operator()(argument_type& theArg) const
{
theArg.clear();
}
Line 284
void
operator()(argument_type thePair) const
{
makeXalanDestroyFunctor(thePair.second)(thePair.second,
m_memoryManager);
}
// The above changes will resolve compiler errors without introducing other
problems.
Sincerely,
Steven J. Hathaway
PROOF-OF-CORRECTNESS ANALYSIS
=============================
//
// STL Functors "operator()"
//
// Are simple template classes that overload the "operator()"
//
// STL unary_function
// Base class for all function classes that represent unary operations.
// It provides standard names for argument and result types.
template<typename Arg, typename Result>
struct unary_function
{
typedef Arg argument_type;
typedef Result result_type;
};
// STL binary_function
// Base class for all the function classes that represent binary operations.
// It provides standard names for argument and result types.
template<typename Arg1, typename Arg2, typename Result>
struct binary_function
{
typedef Arg1 first_argument_type;
typedef Arg2 second_argument_type;
typedef Result result_type;
};
//
// XalanDestroyFunctor
//
template<class Type>
struct XalanDestroyFunctor
{
void operator() (Type& theArg)
{
theArg.~Type();
}
void operator() (Type* theArg)
{
theArg.~Type();
}
void operator() (const Type* theArg)
{
(*this)(const_cast<Type*>(theArg));
}
void operator() (Type* theArg, MemoryManager& theMemoryManager)
{
if (theArg != 0)
{
(*this)(*theArg);
theMemoryManager.deallocate(theArg);
}
}
void operator() (const Type* theArg, MemoryManager& theMemoryManager)
{
(*this)(const_cast<Type*>(theArg), theMemoryManager);
}
}
//
// makeXalanDestroyFunctor
//
template<class Type>
XalanDestroyFunctor<Type>
makeXalanDestroyFunctor(const Type*)
{
return XalanDestroyFunctor<Type>();
}
//
// DeleteFunctor : Functor to delete objects used in STL iteration algorithms
//
template <class Type>
struct DeleteFunctor: public unary_function<const Type*, void>
{
typedef unary_function<const Type*, void> BaseClassType;
typedef typename BaseClassType::result_type result_type; // (void)
typedef typename BaseClassType::argument_type argument_type; // (const Type
*)
...
result_type // (void)
operator()(argument_type thePointer) const // thePointer = (const Type *)
{
makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
}
...
// Note: The above result_type is actually a void type and
// therefore the operator() should have no return statement.
//
// The actual operator()((const Type *) thePointer) becomes:
// {
// if (thePointer != 0)
// {
// (*this)(*thePointer); // (this) becomes thePointer class instance.
// m_memoryManager.deallocate(thePointer);
// // Deallocate with MemoryManager associated with this class.
// // There is no return. m_memoryManager.deallocate() is a void method.
// }
// }
//
was (Author: shathaway):
Compiler Warnings JIRA XALANC-570
---------------------------------
Adding "return" to the template operator() functions is NOT TO BE DONE!
See: PROOF-OF-CORRECTNESS ANALYSIS
If you examine the content of (xalanc/Include/STLHelper.hpp)
you will notice that inside the template<argtype, void>
argument_type = (argtype)
result_type = void
Some C++ compilers get confused when a void type gets renamed.
Therefore, the only code fix to resolve the compiler warnings
is to replace "result_type" with "void" in the appropriate places
in the code.
Line 127
void
operator()(argument_type thePointer) const
{
makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
}
Line 245
void
operator()(argument_type& theArg) const
{
return theArg.clear();
}
Line 284
void
operator()(argument_type thePair) const
{
return makeXalanDestroyFunctor(thePair.second)(thePair.second,
m_memoryManager);
}
// The above changes will resolve compiler errors without introducing other
problems.
Sincerely,
Steven J. Hathaway
PROOF-OF-CORRECTNESS ANALYSIS
=============================
//
// STL Functors "operator()"
//
// Are simple template classes that overload the "operator()"
//
// STL unary_function
// Base class for all function classes that represent unary operations.
// It provides standard names for argument and result types.
template<typename Arg, typename Result>
struct unary_function
{
typedef Arg argument_type;
typedef Result result_type;
};
// STL binary_function
// Base class for all the function classes that represent binary operations.
// It provides standard names for argument and result types.
template<typename Arg1, typename Arg2, typename Result>
struct binary_function
{
typedef Arg1 first_argument_type;
typedef Arg2 second_argument_type;
typedef Result result_type;
};
//
// XalanDestroyFunctor
//
template<class Type>
struct XalanDestroyFunctor
{
void operator() (Type& theArg)
{
theArg.~Type();
}
void operator() (Type* theArg)
{
theArg.~Type();
}
void operator() (const Type* theArg)
{
(*this)(const_cast<Type*>(theArg));
}
void operator() (Type* theArg, MemoryManager& theMemoryManager)
{
if (theArg != 0)
{
(*this)(*theArg);
theMemoryManager.deallocate(theArg);
}
}
void operator() (const Type* theArg, MemoryManager& theMemoryManager)
{
(*this)(const_cast<Type*>(theArg), theMemoryManager);
}
}
//
// makeXalanDestroyFunctor
//
template<class Type>
XalanDestroyFunctor<Type>
makeXalanDestroyFunctor(const Type*)
{
return XalanDestroyFunctor<Type>();
}
//
// DeleteFunctor : Functor to delete objects used in STL iteration algorithms
//
template <class Type>
struct DeleteFunctor: public unary_function<const Type*, void>
{
typedef unary_function<const Type*, void> BaseClassType;
typedef typename BaseClassType::result_type result_type; // (void)
typedef typename BaseClassType::argument_type argument_type; // (const Type
*)
...
result_type // (void)
operator()(argument_type thePointer) const // thePointer = (const Type *)
{
makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
}
...
// Note: The above result_type is actually a void type and
// therefore the operator() should have no return statement.
//
// The actual operator()((const Type *) thePointer) becomes:
// {
// if (thePointer != 0)
// {
// (*this)(*thePointer); // (this) becomes thePointer class instance.
// m_memoryManager.deallocate(thePointer);
// // Deallocate with MemoryManager associated with this class.
// // There is no return. m_memoryManager.deallocate() is a void method.
// }
// }
//
> Removal of compiler warnings from STLHelper.hpp
> -----------------------------------------------
>
> Key: XALANC-570
> URL: https://issues.apache.org/jira/browse/XALANC-570
> Project: XalanC
> Issue Type: Bug
> Components: XalanC
> Affects Versions: 1.9
> Environment: g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-52), Intel
> Reporter: David Singleton
> Priority: Minor
>
> When programs using Xalan (or Xalan itself) are compiled, the following
> compiler warning is generated from 3 points in STLHelper.cpp (lines 127, 245
> and 284):
> /home/singleto/Xalan_prob/xml-xalan/c/src/xalanc/Include/STLHelper.hpp: In
> member function `std::unary_function<const _Tp*, void>::result_type
> xalanc_1_9::DeleteFunctor<Type>::operator()(std::unary_function<const _Tp*,
> void>::argument_type) const':
> /home/singleto/Xalan_prob/xml-xalan/c/src/xalanc/Include/STLHelper.hpp:127:
> warning: no
> return statement in function returning non-void
> /home/singleto/Xalan_prob/xml-xalan/c/src/xalanc/Include/STLHelper.hpp: In
> member function `std::unary_function<_Tp, void>::result_type
> xalanc_1_9::ClearFunctor<Type>::operator()(std::unary_function<_Tp,
> void>::argument_type&) const':
> /home/singleto/Xalan_prob/xml-xalan/c/src/xalanc/Include/STLHelper.hpp:245:
> warning: no
> return statement in function returning non-void
> /home/singleto/Xalan_prob/xml-xalan/c/src/xalanc/Include/STLHelper.hpp: In
> member function `std::unary_function<T::value_type&, void>::result_type
>
> xalanc_1_9::MapValueDeleteFunctor<T>::operator()(std::unary_function<T::value_type&,
> void>::argument_type) const':
> /home/singleto/Xalan_prob/xml-xalan/c/src/xalanc/Include/STLHelper.hpp:284:
> warning: no
> return statement in function returning non-void
> An inspection of the code ( see below) shows that in all three cases no value
> is returned.
> Line 127
> result_type
> operator()(argument_type thePointer) const
> {
> makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
> }
> Line 245
> result_type
> operator()(argument_type& theArg) const
> {
> theArg.clear();
> }
> Line 284
> result_type
> operator()(argument_type thePair) const
> {
> makeXalanDestroyFunctor(thePair.second)(thePair.second,
> m_memoryManager);
> }
> The easiest way to solve the problem (or at least to get the compiler
> warnings to go away) ist to add a return, as shown below:
> Line 127
> result_type
> operator()(argument_type thePointer) const
> {
> return makeXalanDestroyFunctor(thePointer)(thePointer,
> m_memoryManager);
> }
> Line 245
> result_type
> operator()(argument_type& theArg) const
> {
> return theArg.clear();
> }
> Line 284
> result_type
> operator()(argument_type thePair) const
> {
> return makeXalanDestroyFunctor(thePair.second)(thePair.second,
> m_memoryManager);
> }
> Perhaps I have overlooked something here, but I offer my correction in any
> case. I will send the amended code by email
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
