Integer by reference..

[rabbit]

What?  That's the entire point of Java: an overabundance of objects.  You're not supposed to return a pointer, you're supposed to return an object.

[kalaka]

It's what anyone who's gotten past chapter 2 of "Java for Dummies" should think.

Crap, I knew I should've read chapter 2...

[Sidoh]

What?  That's the entire point of Java: an overabundance of objects.  You're not supposed to return a pointer, you're supposed to return an object.

I said "you bug me," not "I'm unable to decipher your hyperbole."

[iago]

If you need to return more than a single variable, then you probably have a design issue. 

I think it might work best like this (in general):

int val1, val2;
VersionDatachecker vd = new VersionDatachecker();
vd.go(list, of, variables);
val1 = vd.getVal1();
val2 = vd.getVal2();

That's likely a cleaner design, and more "proper", in many respects.

Creating an object to return a parameter value is a gross kludge. It was a killable offense back when I was a marker.

[Joe]

Here you go:

Code: [Select]

package versioning;

public class CheckRevisionResults
{

private int m_verhash;
private int m_checksum;
private byte[] m_statstring;

public CheckRevisionResults(int verhash, int checksum, byte[] statstring)
{
m_checksum = checksum;
m_verhash = verhash;
m_statstring = statstring;
}

public int getChecksum()
{
return m_checksum;
}

public int getVerhash()
{
return m_verhash;
}

public byte[] getStatstring()
{
return m_statstring;
}
}
getVersionCheck returns that.

By the way, I passed Lockdown with SEXP, in case anyone cares.

[Chavo]

If you need to return more than a single variable, then you probably have a design issue. 

Returning an object that acts as a data structure encapsulating a number of related variables IS returning a single variable (or at least a reference to one).  That's not a design issue... Writing 2 methods just to return 2 seperate values that you are going to combine anyway or that causes unnecessary copying of code is a bigger design problem than returning an object instead of a primitive ><

nt val1, val2;
VersionDatachecker vd = new VersionDatachecker();
vd.go(list, of, variables);
val1 = vd.getVal1();
val2 = vd.getVal2();

This makes sense when Val1 and Val2 are not dependent variables or are not going to be used in the same place.

int val1, val2;
VersionDatachecker vd = new VersionDatachecker();
vd.go(list, of, variables);
val1 = vd.getVal1();
val2 = vd.getVal2();
computeNewVal(val1, val2);

If I'm just passing those 2 variables into a new method, that's fine, it is more flexible (not more 'correct').  It is not incorrect to write a method such that:

int val1, val2;
VersionDatachecker vd = new VersionDatachecker();
vd.go(list, of, variables);
vallist = vd.getVariableList();
vallist = computeNewVals(vallist);
//or even better
computeNewVals(vd);

If you are writing a utility class and looking to maximize reusability, it makes sense to break things down, but that's hardly a design issue to not use Objects where its easier or makes sense.

[nslay]

If you need to return more than a single variable, then you probably have a design issue. 

I think it might work best like this (in general):

int val1, val2;
VersionDatachecker vd = new VersionDatachecker();
vd.go(list, of, variables);
val1 = vd.getVal1();
val2 = vd.getVal2();

That's likely a cleaner design, and more "proper", in many respects.

Creating an object to return a parameter value is a gross kludge. It was a killable offense back when I was a marker.

Just to expand on what unTactical said, as well as being a big C/C++/Fortran programmer (though I hate Fortran!), it is not only common to wish to return multiple pieces of data, but the ability to do so is built into all three of these languages.
While, C/C++ provide structs and classes, to "return" multiple pieces of data, Fortran actually defines a class of "subprogram" known as a "subroutine"
A subroutine is basically a C++ void function that accepts all references.
Here's a practical example where I want two pieces of data returned in fortran (95):

Code: [Select]

SUBROUTINE boxmuller(x,y)
  IMPLICIT NONE
  DOUBLE PRECISION, PARAMETER :: PI = 3.14159265359d0
  DOUBLE PRECISION, INTENT(OUT) :: x, y
  DOUBLE PRECISION :: u1, u2
  CALL RANDOM_NUMBER(u1)
  CALL RANDOM_NUMBER(u2)
  x = SQRT(-2.d0*LOG(u1))*COS(2.d0*PI*u2)
  y = SQRT(-2.d0*LOG(u1))*SIN(2.d0*PI*u2)
END SUBROUTINE boxmullerThis returns two independent variates distributed on N(0,1) generated from Box-Muller.

Here's a practical example in C

Code: [Select]

int tunman_getaddr( struct tunman *tn, struct sockaddr *addr, struct sockaddr *b
road ) {
        struct ifconf ifc;
        struct ifreq ifr;
        int s = socket( AF_INET, SOCK_DGRAM, IPPROTO_UDP );
        if ( s == -1 ) return -1;
        memset( &ifc, 0, sizeof(ifc) );
        strncpy( ifr.ifr_name, tn->ifnam, sizeof( ifr.ifr_name ) );
        ifc.ifc_len = sizeof(ifr);
        ifc.ifc_req = 𝔦
        if ( ioctl( s, SIOCGIFCONF, &ifc ) == -1 ) {
                close( s );
                return -1;
        }
        close( s );
        memcpy( addr, &ifc.ifc_req->ifr_addr, sizeof(*addr) );
        memcpy( broad, &ifc.ifc_req->ifr_broadaddr, sizeof(*broad) );
        return 0;
}
In this example, I not only return an indicator for error, but I also return two pieces of information, an interface's IP address and broadcast address.  The ioctl() SIOCGIFCONF also returns a buffer of ifreqs that hold the interface's IP address and aliases.  These types of operations are very common in Unix...doing something like:
getipaddr("eth0", &ip);
getbroad("eth0",&broad);
getmask("eth0", &mask);
getstate("eth0", &up );
etc...is extremely redundant!

[MyndFyre]

In this example, I not only return an indicator for error, but I also return two pieces of information, an interface's IP address and broadcast address.  The ioctl() SIOCGIFCONF also returns a buffer of ifreqs that hold the interface's IP address and aliases.  These types of operations are very common in Unix...doing something like:
getipaddr("eth0", &ip);
getbroad("eth0",&broad);
getmask("eth0", &mask);
getstate("eth0", &up );
etc...is extremely redundant!

Ahh, very true.  *HOWEVER*, the C language was developed before structured exception handling was really a standard (or at the very least, it wasn't considered a major feature of C).  It isn't appropriate in languages with SEH (except C++ apparently, probably because of its C roots) to return error codes.

[Joe]

Mine was somewhat the same idea. The way RCRS worked is each field was a different packet, but now that I'm using BNLS, it seemed impracticle to send the same packet three times over in the seperate functions.