Thread: tertiary comparison

>won't this work?
Only if you're trying to compare boolean values and not object values.

That makes sense.

What about those functions like printf() that have variably sized argument lists? That way in the function you could put the comparisons into a loop breaking at the first difference, and when you want to compare (x) variables, you only have to type each variable name once in the function call. I don't know the exact syntax of this, but from what I've read (sooo long ago), something to this effect should be possible.

Hope this helps!

**EDIT**
Hmm, come to think of it I believe you'd also need variable type and count parameters, and you'd need to figure something out to take the different types into account. If it were C++ I'd suggest something along the lines of templates, but... *shrug*

What I was trying to do was check for a win in a tic-tac-toe game. The board is stored in a struct called Board, the board is really a 3 by 3 array of chars. I am checking rows, columns, and diaganols. So with the comparison, it ended up huge, like this.

Code:

if((curBoard->tiles[0][0] == curBoard->tiles[0][1]) && (curBoard->tiles[0][1] 
== curBoard->tiles[0][2]) && curBoard->tiles[0][0] != 0) {
//code
}
...

I guess it isn't really that long. It works, and it isn't obfuscated.

I suppose in this case that would be fine. But I'm going to try the variable argument list idea anyway, just for fun and also in case I should ever *need* it in the future.

**P.S. Would anyone know anything about how efficient such a solution would be? Because by my reasoning there would be roughly double the tests due to the loop, and it would be useless if the function made everything run sluggishly.

Ok, well I went and wrote up a template function that does the x comparisons for you:

Code:

template <typename T>
bool compare(int equals, int diffs, T** traverser, ...)
{
   --equals;
 
   //Go to position of first variable
   unsigned char* memPtr = (unsigned char*)&traverser;
   memPtr += sizeof(traverser);
 
   //Get an iterator for the variable list
   traverser = (T**)memPtr;
   T& first = **traverser;
   ++traverser;
 
   //Compare for equality
   for(int i = 0; i < equals; ++i)
   {
	  if(**traverser != first)
		 return false;
	  ++traverser;
   }
 
   //Compare remaining arguments with first value, for inequality this time
   for(i = 0; i < diffs; ++i)
   {
	  if(**traverser == first)
		 return false;
	  ++traverser;
   }
 
   return true;
}
 
int main()
{
   int a,b,c,d,e,f,g,h;
 
   a = b = c = d = 4;
   e = f = g = h = 6;
 
   int** traverser = NULL;
   if(compare(4, 4, traverser, &a, &b, &c, &d, &e, &f, &g, &h))
	  //do something
 
   return 0;
}

Or, if you don't like templates (i.e. if you use C, as you probably do), you can specialize it for a specific type by replacing every instance of T with the type name (and don't bother passing the T*, just declare a local variable that does the same thing). The parameters are:
1) Number of variables to be compared for equality
2) Number of variables following, to be compared for inequality with the first variable
3) A (type)**, used for type resolution (template stuff)
4) A list of pointers to variables to be compared

Let me know what you think

The first thing that jumped out after a quick glance was this:

Code:

char* memPtr = (char*)&traverser;

You should consider using unsigned char instead of char in this case.

I'm in a bit of a hurry, but I'll look closer at it later.

Is there any particular reason for this? I know unsigned char is usually used when handling generic bytes, but I used char for its 1-byte-ness, and pointer-wise I don't see any difference between any datatypes other than the 'jump' size.

**EDIT** I modified the code somewhat, got rid of some unneeded pointer shuffling and added commenting. I also changed char* to unsigned char* And variables are passed by pointer and not by value.

The above post has been edited to reflect the new changes.

>Is there any particular reason for this?
I sure hope so, otherwise I would look like a fool for suggesting it.

Type punning (which is what the technique you are using is called) is only guaranteed to be safe with unsigned char representations. The argument of trap representations, potential signedness of vanilla char and padding will show up most of the time in this case, but you aren't likely to be working on a system that has such things. Still, the possibility is there; hence my suggestion that you consider using a pointer to unsigned char rather than a pointer to char.

[over the head]
The argument of trap representations, potential signedness of vanilla char and padding will show up most of the time in this case, but you aren't likely to be working on a system that has such things.
[/over the head]



So... uh, you mean pointer types actually do something other than help the compiler catch stray errors (and vary increment size)? I've been coding for the past few years on the assumption that pointers are all represented in the same way and do the same thing

P.S. Well, I changed that already anyways... but do you have any other suggestions?

I wish I would wake up tomorrow and have prelude's knowledge...

>I've been coding for the past few years on the assumption that pointers are all represented in the same way and do the same thing
How do you explain the difference between object and function pointers? Just kidding, it isn't the pointer itself but the underlying type that's the problem. If you access the bytes of an object through a pointer to char, it's possible for that char value to be interpreted as a trap representation whereas if that byte is represented as an unsigned char, it's guaranteed not to be.

Put simply, only a pointer to unsigned char is guaranteed to portably represent the bytes of an object even though you probably won't see a system where using a pointer to char would cause a problem.

>>How do you explain the difference between object and function pointers?
What difference? Even GetProcAddress() supposedly will return the address of an object if you ask for one

>>Just kidding, it isn't the pointer itself
*wipes cold sweat off forehead*

>>it's possible for that char value to be interpreted as a trap representation
I'll do some research on 'trap representation', but how does this apply? I don't believe I ever dereference the pointer (get the value), merely shift it to point at another address and assign it to a pointer of another type.

>What difference?
They aren't represented the same. For instance, you can't convert a function pointer to a pointer to void.

>I'll do some research on 'trap representation'
I'll save you the effort, a trap representation is an object representation that doesn't represent a value of the object type. "Bad value" in laymans terms.

>I don't believe I ever dereference the pointer (get the value)
<Salem's burns impression>Excellent, Smithers.</Salem's burns impression>

See? You're learning already. I was hoping you'd catch that. And my answer is that you should strive for excellence even when it isn't strictly required. That way you'll be in the habit of doing things properly and you won't get caught off guard in situations where you do access the value.

>>you can't convert a function pointer to a pointer to void.
Strange, I remember bithub saying that you could use GetProcAddress() to get the address of a variable in a DLL (here). I suppose I'll have to check on that.

>>representation that doesn't represent a value of the object type. "Bad value" in laymans terms.
Wild guess: You mean in case a char isn't really 8 bits, you might end up with a screwed up value due to hidden bits? Because I can't think of any strictly 'bad' value for a char - or for any other datatype.

>>See? You're learning already. I was hoping you'd catch that.
I feel like I'm in school, and the teacher just made a mistake that she's trying to cover up

>>(the rest of the post)
I suppose so, that's why I modified my code to reflect your suggestion even before getting your explanation Although I can't think of any situation that I'd do this in other than data parsing (winsock, or compression stuff like earlier).
[edit]Actually, this sort of IS data parsing So I can't think of any situation in which I would dereference the pointer.[/edit]