h a l f b a k e r yThis product is not intended to diagnose, treat, cure or prevent any disease.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
I always find it odd that with C,C++ and
Java you can pass in almost any number of
arguments but only return one thing like
this.
public int functionamehere( int
argument1, int argument2, String
argument3 )
{
return argument1 * argument2 ;
}
so you get
int five = functionmehere(
3, 5, hell);
If you want to pass two things out you
need to pass one as an argument. This
creates problems in laguages/systems like
CORBA and network RPC style languages
what is being passed as an argument and
what is going to be altered.
What I want is a version of java/c/c++/
whatever where you can return more than
one value.
public (int result1 , int result2 )
functionNameHere( int agument1 , int
argument2 , Stiring argument3))
{
result1 = argument1 * argument2;
result2 = (, argument1 argument2
return ( result1, result2 ) ;
}
so you get
int fifteen, two ;
( fifteen, two ) = functionNameHere
( 3,5,things);
this simplifies things so anything that is
an argument is being passed in and
anything being returned is passed out. We
can even say
protected (int result)functionNameHere
(int result){ return result ; }
that is we are going to pass the argument
(possibly modified) back. With a little luck
and a bit of guile we might even be able to
use this to move register frames around
more efficiently. This also means we avoid
special means for values like null. I believe
we use say NULL if we cannot open an file
not because this is a good idea then what
if I want to return a value that expains the
error ? with multiple returns we get
FILE *f;
Int error ;
(error , f ) = fopen(filename , r);
[link]
|
|
Python and recent JavaScript ("destructuring assignment") do something like this, and people seem to like it. |
|
|
It translates pretty straightforwardly into passing in pointers and returning by assignment to those dereferenced pointers (or, in C++, passing in result parameters by reference); the compiler/optimizer is free to draw inferences about how to do that efficiently. |
|
|
A disadvantage of the multi-return style vs the passing-in-a-pointer style is that the latter, by convention, often lets you signal disinterest in a result by passing in NULL - that's handy, because you don't have to declare a variable just to hold a result you're not using. |
|
|
An alternative solution to the problem of returning either a thing or an error is exceptions. |
|
|
Can't you return an array? |
|
|
[phundug] just what I was thinking. Return an array, or a reference to an array, and return as much data as you want. At least that is what I tend to do in Perl. |
|
|
Agree with all, but pursuing (or reiterating) on a more object-oriented theme; with c++ and java, you could create and return data within a some kind of standard Return_Object_Class. And have this class encapsulate clean and easy management of an array, providing a simple to handle interface where it's empty, or only has one element. The whole oo thing about java and c++ is to build your own interfaces, nuances and preferred ways of working (at least, that's how it seems to me - members of professional dev teams might be wincing at the thought of all that twisty and non standard code, but I'm not in a dev team, so it's not important right now) |
|
|
Of course, you would have to tweak a number of existing functions in order to accommodate something like this, but it's perfectly feasible (if potentially clumsy and non-performant) to build a class library in order to support you programming (in almost) any way you want. |
|
|
I'm with [inventorist] on this one. What he suggests is an easier way to manipulate output variables for functions. I think this is what HLL are all about. Perhaps I am wrong, but the reason I choose C++ instead of Assembler might be similar to the reason I would choose a language upgraded in inventorist's proposed manner instead of the classic C++ or Java. |
|
|
With C all that is required is to return a pointer to a structure containing all you need. If you really think more return variables are a good idea, you could rewrite the C call binding to return more variables, it doesn't look nice though. (don't know how to do this in C++ or java). Its not portable as the binding changes between processors and between different compilers on the same processor. My feeling and experience though is a vote for [bigsleep] on this. With well structured code multiple returns aren't ever really necessary. Also "nil reperio rota" (not find again the wheel) so read the manual. |
|
|
eg. The file example could be re-written as |
|
|
if ((fptr = fopen(name,"r")) == NULL) |
|
|
perror("can't open file cos:-"); |
|
|
This will give you the error message and the reason why on stdout. |
|
|
Just about every compiler writer while playing with their own language will have implemented this feature. There's even a good justification of it in terms of functional languages, because you can use copy-in/copy-out semantic (params are in, results are out) to optimise code more aggressively. |
|
|
It maps well to stack based languages like forth or pop2 with an explicit user stack, because args are pushed on the stack before calling, and results are left on the stack on return. |
|
|
However very few real languages actually do this. The reason why is left as an exercise for the reader. |
|
|
(Hint: it's very similar to why we don't do long-haul shipping by zeppelin even though everyone who examines the economics of doing so comes away scratching their heads and wondering why it isn't already being done...) |
|
| |