Dave,
Thanks on your research into the actual spec's regarding (return void;).
My knowledge base has increased !!!
Sincerely,
Steven J. Hathaway
> On 7/14/2011 10:14 AM, shath...@e-z.net wrote:
>>> On 7/11/2011 1:09 PM, shath...@e-z.net wrote:
>>>> There are lots of places in the XALANC code where
>>>> using STL (Standard Template Library) interface
>>>> renames the type 'void' to 'result_type' and therefore
>>>> confuses GCC and other compilers, resulting in
>>>> warnings - requesting a return statement.
>>>>
>>>> A 'void' function result type means that there
>>>> should not be a return statement.
>>>>
>>>> The file STLHelper.hpp is just one instance in the
>>>> XALANC code. See: JIRA XALANC-570
>>>>
>>>> The warnings do not create bad code! I don't have
>>>> the time to find all such occurrences at this time.
>>>>
>>>> To maintain consistency in the code base, XALANC-570
>>>> should probably not be committed, maintaining
>>>> compatibility throughout the code base.
>>> These are unfortunately compiler limitations. Returning void is
>>> explicitly allowed by the standard for the very purpose of being able
>>> to
>>> write generic code like this.
>>>
>>> Can you be more explicit about which version of GCC is issuing this
>>> warning?
>>>
>>> Dave
>>>
>>
>> JIRA XALANC-570
>> Environment:
>> g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-52), Intel
>>
>> Should this be a problem?
>>
>> STL defines the unary_function class template as:
>>
>> template<typename Arg, typename Result>
>> struct unary_function {
>> typedef Arg argument_type;
>> typedef Result result_type;
>> };
>>
>> The xalanc/Include/STLHelper.hpp - for example - contains:
>> =======
>> struct DeleteFunctor : public std::unary_function<const Type*, void>
>> {
>> typedef std::unary_function<const typename T::value_type&, void>
>> BaseClassType;
>> typedef typename BaseClassType::result_type result_type;
>> typedef typename BaseClassType::argument_type argument_type;
>>
>> // Now: the typedef to result_type is actually 'void'
>>
>> result_type
>> operator()(argument_type thePointer) const
>> {
>> makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
>> }
> Ah, this is just a bug that can be fixed by adding a return statement:
>
> return makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager);
>
> I misunderstood your original post.
>
>>
>> // The makeXalanDestroyFunctor(thePointer)(thePointer, m_memoryManager)
>> // evaluates to a function that has as 'void' return type.
>>
>> private:
>> MemoryManager& m_memoryManager;
>> }
>> =======
>>
>> The GNU gcc/g++ 3.2.3 compiler complains that 'result_type' for
>> operator()
>> is non-void and therefore wants the line to have a return:
>>
>> return makeXalanDestroyFunctor(thePointer)(thePointer,
>> m_memoryManager);
>>
>> C/C++ standard says that functions declared as 'void' return type
>> should not have a return statement.
> It doesn't say this. In fact, it says the opposite:
> From 3.9.1.9
>
> "The void type has an empty set of values. The void type is an
> incomplete type that cannot be completed. It is used as the return type
> for functions that do not return a value. Any expression can be
> explicitly converted to type cv void (5.4). An expression of type void
> shall be used only as an expression statement (6.2), as an operand of a
> comma expression (5.18), as a second or third operand of ?: (5.16), as
> the operand of typeid, or as the expression in a return statement
> (6.6.3) for a function with the return type void."
>
> Note that very last part of the section explicitly allows a return
> statement in this case.
>
> From 6.6.3:, sections 2 and 3:
>
> "A return statement without an expression can be used only in functions
> that do not return a value, that is, a function with the return type
> void, a constructor (12.1), or a destructor (12.4). A return statement
> with an expression of non-void type can be used only in functions
> returning a value; the value of the expression is returned to the caller
> of the function. The expression is implicitly converted to the return
> type of the function in which it appears. A return statement can involve
> the construction and copy of a temporary object (12.2). Flowing off the
> end of a function is equivalent to a return with no value; this results
> in undefined behavior in a value-returning function.
>
> A return statement with an expression of type cv void can be used only
> in functions with a return type of cv void; the expression is evaluated
> just before the function returns to its caller."
>
>>
>> It is unclear what happens to C/C++ compilers and linkers
>> when the following is actually coded:
>>
>> return void;
>>
>> Note: A 'void' return type means there is no return value.
>> Interpreting the result of (return void;) may be undefined
>> garbage instead of zero or null.
>>
>> The problem here is that the GNU gcc/g++ compiler either looses
>> track of 'void' type across typedef, or cannot find the
>> 'void' return type when using a function set selector such as
>> makeXalanDestroyFunctor(thePointer).
>>
>> The fix to resolve the return type warnings where 'void'
>> is known is to explicitly specify 'void' as the result_type
>> on a STL operator() definition.
> I can just fix the code so there's a return statement. This is
> essentially what you suggested in XALANC-570, I believe.
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org
> For additional commands, e-mail: xalan-dev-h...@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org
For additional commands, e-mail: xalan-dev-h...@xml.apache.org
