# Thread: Not having functions return values via pointer arguments

1. ## Not having functions return values via pointer arguments

There are various math functions which currently return a second value via a pointer given in the argument list. For example:
Code :
```gentype fract (gentype x, gentype *iptr)
gentype sincos (gentype x, gentype *cosval)```
A common use for sincos might be the construction of rotated unit vectors, where it would be useful to write:
Code :
```float a;
vec2 v;
v = sincos(a);```
Unfortunately with sincos in it's current form it's impossible to do this without a temporary variable, as taking the address of a vector component is illegal.
Code :
```//This is illegal
vec2 v;
float a;
v.x = sincos(a, &v.y);

// So it has to be this
float t;
v.x = sincos(a, &t);
v.y = t;```

This is just one use case though, and having (for example) sincos return a vec2 would stop the following
Code :
```float16 a;
float16 sina, cosa;
sina = sincos(a, &cosa);```

The problem here is that the function is really trying to return two values, and C has the limitation that it only has a single return value. It could return a struct, but that would need the definition of a struct for every function that wanted to do this, including all overloaded versions. Language such as Python solved this by using n-ples (n element tuples) and I think the would be a good addition to the OpenCL language. The result would be code like this:
Code :
```float a1;
vec2 v;
(v.x, v.y) = sincos(a1);

float16 a2, sina, cosa;
(sina, cosa) = sincos(a2);

//Dummy definition of sincos to show function definition
(gentype, gentype) sincos(gentype angle) {
return (sin(a), cos(a));
}```

In some ways this can be thought of as an anonymous struct. Maybe normal brackets are the wrong thing to use to group n-ples, as I think that return statement might already have a meaning, but that's just syntax. Adding this would make code nicer to read, and has the advantage that it's obvious to the compiler that the variable 'cosa' in the above example is being overwritten, meaning any previous value does not need to be preserved making some optimisations possible.

2. ## Re: Not having functions return values via pointer arguments

I suspect people will object to this on the basis that it's not C (or even C++) like. While it's an elegant solution, my impression is that there is a huge drive to be as close to generic C as possible. (With all the pluses and minuses that entails.)

3. ## Re: Not having functions return values via pointer arguments

I know what you mean, but I hope you're not right.

We already have vector type, and different memory spaces, so there's no getting away from the fact that the OpenCL language* isn't C. It would be a shame if OpenCL is held hostage to C's known problems and limitations.

Pointer abuse would be one at the top of my list to solve as it causes C so many problems (buffer overruns, variable aliasing). While I don't advocate taking anything away from pointers, I'd like to see it possible to get away from using them when you're missing a language feature.

* We need a shorthand name for this language (like GLSL), but CLL or CLKL don't work in my opinion

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•