Is there any reasonable use of a function returnin

问题:

Here is an (artificial) example of using a function that returns an anonymous struct and does "something" useful:

#include <iostream>

template<typename T>
T* func(T* t, float a, float b) {
    if(!t) {
        t = new T;
        t->a = a;
        t->b = b;
    } else {
        t->a += a;
        t->b += b;
    }
    return t;
}

struct {
    float a, b;
}* foo(float a, float b) {
    if(a==0) return 0;
    return func(foo(a-1,b), a, b);
}

int main() {
    std::cout << foo(5,6)->a << std::endl;
    std::cout << foo(5,6)->b << std::endl;

    void* v = (void*)(foo(5,6));
    //[1] delete f now because I know struct is floats only.
    float* f = (float*)(v);

    std::cout << f[0] << std::endl;
    std::cout << f[1] << std::endl;

    delete[] f;

    return 0;
}

There are a few points I would like to discuss:

1. As is apparent, this code leaks, is there anyway I can NOT leak without knowing what the underlying struct definition is? see Comment [1].
2. I have to return a pointer to an anonymous struct so I can create an instance of the object within the templatized function func, can I do something similar without returning a pointer?
3. I guess the most important, is there ANY (real-world) use for this at all? As the example given above leaks and is admittedly contrived.

By the way, what the function foo(a,b) does is, to return a struct containing two numbers, the sum of all numbers from 1 to a and the product of a and b.

Maybe the line new T could use a boost::shared_ptr somehow to avoid leaks, but I haven't tried that. Would that work?

I think I was just trying to delete the anonymous struct as an array of floats, something like float* f = new float[2]. Which might be wrong, as the comment below suggests, so what can be done? can I delete at all?

I can compile and run this code "as-is" on VS2008, maybe some non-standard extensions might be being used by VS, but it does run and gives 15 and 30 as the answer.

From the answers I believe this contraption is a VS2008 specific entity, it is not standards compliant and thus not portable. Too bad though, I would have liked to see what voodoo the Stackoverflow or Boost people came up with if this was in their arsenal :). Thanks all.

回答1:

For now, your code is not portable; it will, for example, not build with gcc.

Section 14.3.1/2 of the standard says:

A local type, a type with no linkage, an unnamed type or a type
compounded from any of these types shall not be used as a template-
argument for a template type-parameter.

See item 488 in the C++ Standard Core Language Defect Reports, Revision 69 and Paper N2657 for one possible evolution.

UPDATE 1

Assuming that your code were well-formed, then:

1. you may be able to rewrite:

   std::cout << foo(5,6)->a << std::endl;
   

   as

   std::cout << std::auto_ptr(foo(5,6))->a << std::endl;
   

2. you may return an anonymous struct by-value provided that the anonymous struct had a constructor taking another type (anonymous or not, that you'd be able to initialize inside the body of your method) -- except, of course, how do you specify a constructor for an anonymous struct? :)

3. no real-world use that I can see other than an extremely convoluted way of trying not to assign an explicit name to the structure; one would typically use anonymous structs (not technically legal in C++, but supported by various compilers as extensions) in order to not pollute the namespace, typically by instantiating one right away (you may for example see one-shot functors being instantiated and passed down as anonymous structs -- again, technically not legal C++.)

UPDATE 2

Thank you gf for the link to the relevant portion of the C++ standard concerning new types which may not be defined in a return type.

UPDATE 3

Bringing this one out here from the comments: calling delete[] on memory allocated with new (as opposed to new[]) is an invitation to heap corruption. Calling delete on a pointer whose type you do not know is technically undefined (which destructor should get called?) but in the case of PODs (your anonymous struct being one) you can get away with it in this horrible hackish way:

 delete (int*)f;

Of course, were your code magically well-formed, std::auto_ptr would have been able to retain the anonymous type and would have taken care of calling delete for you correctly and gracefully.

回答2:

What you are doing is not possible in standard C++ - type definitions are not allowed in return types as per §8.3.5/6 (function declarators, C++03):

Types shall not be defined in return or parameter types.

Visual Studio is non-compliant in this case.

回答3:

C++ Standard does not allow anonymous structures.

回答4:

I can't think of any reasonable usage. Apart the memory leaks, this is a very unreadable way of achieving the goal you want. It makes your reader think a lot what the code is doing. And also it is not known who should delete 'f' in the main(). And should it be deleted with delete[] or delete?

I would use a class taking the 'a' and 'b' in the constructor. It will have two methods for getting the two calculated struct members. And inside the class there will be private mehotds, using plain loops to calculate the things you want. Then your API will look like this:

void main()
{
   MyCalculator myCalc(5, 6);
   double sumOfAllNumbers = myCalc.getSumOfAllNumbers();
   double product = myCalc.getProduct();
}

回答5:

A close approximation of an anonymous struct is a tuple. Boost::Tuple is available anywhere now, and there's another in TR1 [which I assume is distributed with VS2008] with a near identical interface.

#include <boost/tuple/tuple.hpp>

template<typename T>
boost::tuple<T, T>* func(boost::tuple<T, T>* t, float a, float b ) {
    if(!t) {
      t = new boost::tuple<T, T>(a, b);
    } else {
      boost::get<0>(*t) += a;
      boost::get<1>(*t) += b;
    }
    return t;
}

boost::tuple<float, float>* foo(float a, float b) {
    if(a==0) return 0;
    return func(foo(a-1,b), a, b);
}

As others have said, the overall scheme is pretty flimsy, but I wanted to focus on the tuple rather than the design.