Author Topic: CustomPacket bug  (Read 9148 times)

Holomorph

  • User
  • *
  • Posts: 32
CustomPacket bug
« on: February 23, 2005, 01:24:06 AM »
OK, I had a packet type I wanted to add a bufffer to, in order to send some more free form data in addition to the other fields in the packet, and so I pretty much based that part off the GNE::CustomPacket.  When trying to use this buffer however, I ran into a problem. I haven't tested an actual CustomPacket to see if it actually exibits the same bug, but I can't see how it is working differently, so I'm assuming it does.

The proble is that the GetBuffer() function returns a buffer, but it is only a copy of the buffer in the packet.  Thus, when you write to it, and then send the packet, the data does not get into the packet to get sent.  I modified my packet to return a pointer to the buffer, then I am able to write to it, and the data is actually sent when I send the packet.

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
CustomPacket bug
« Reply #1 on: February 23, 2005, 08:42:54 AM »
CustomPacket does not return a copy of its buffer.  If you notice, it returns a non-const reference to Buffer.  I checked this in both the CVS and "public" version.  See the prototype:
Code: [Select]
Buffer& CustomPacket::getBuffer()
Gillius
Gillius's Programming http://www.gillius.org/

Holomorph

  • User
  • *
  • Posts: 32
CustomPacket bug
« Reply #2 on: February 23, 2005, 03:55:16 PM »
Hmm, yes well, in any case, when I write to the buffer it returned, that information was not making it into the packet, so I assumed it must somehow be returning a copy.  Maybe I am not understanding how to use it.  If I do this:

Code: [Select]

CustomPacket p;
Buffer b1 = p.getBuffer();
b1 << 2;
Buffer b2 = p.getBuffer();



then b1 and b2 should in fact be the same buffer right?  They should then have the same  position, limit, etc. but I found this was not the case.  b2 had position 0, but b1 had position 4, I believe.  I'm not at home right now so this code and results is basically from memory so I'm not positive how this will work.  Do I have the right idea here though?

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
CustomPacket bug
« Reply #3 on: February 23, 2005, 05:25:22 PM »
No that is wrong.  You are creating a new Buffer when you say Buffer whatever = something.  Here are two valid methods:
Code: [Select]
CustomPacket p;
//method 1
Buffer& buf = p.getBuffer();
buf << whatever;
//method 2
p.getBuffer() << whatever;

The first method creates a reference and assigns p.getBuffer() to that reference.  buf now represents the same variable as the buffer object in the class.  The second method is just without the temporary, is probably more what I was aiming for when I made the method.
Gillius
Gillius's Programming http://www.gillius.org/

Holomorph

  • User
  • *
  • Posts: 32
CustomPacket bug
« Reply #4 on: February 25, 2005, 03:38:09 PM »
ah, ok thanks for the clarification.

you'd think after 4 or 5 years of programming in C++ I'd have a better hanle on the & opperator :P

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
CustomPacket bug
« Reply #5 on: February 25, 2005, 07:50:54 PM »
Actually, I hate to say this, but in this case it is not an operator :(.  It acts similar to a * put on a variable type to make a pointer type.  The & turns the variable in a reference type.  & as an operator either means address-of (which returns a pointer from a reference rather than a reference) or bitwise AND.

EDIT: do you have a suggestion that will make the interface easier to use?  I like APIs that are intuitive, and as you've figured out, getBuffer is not intuitive.

Perhaps I could return a smart pointer or some sort of handle to buffer, so that if you copied it, you still work on the original buffer.  Maybe literally a SmartPtr<Buffer> I can return?  That is less efficient, though, if you know what you are doing, but much less error-prone.
Gillius
Gillius's Programming http://www.gillius.org/

Holomorph

  • User
  • *
  • Posts: 32
CustomPacket bug
« Reply #6 on: March 03, 2005, 10:46:10 PM »
gosh I thought the * was known as the 'dereference' opperator, and in this case the & was the 'reference' opperator, but wasn't aware there was a difference here between the address-of  opperator; might take a little more thought for me to wrap my mind around that one. .

I don't think getBuffer is that unintuitive once the right way to use it is demonstrated.  I think if you put those four lines of example code in the API reference it would not be a problem.  The "p.getBuffer() << whatever;" bit is espacially nice, the other way is the only possib/y tricky/non-intuitive part, but it's pretty trivial to get with an example.

As for returning a smart pointer, that probably depends on how people use/abuse the customPacket.  Efficiency may become an issue for some usage.

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
CustomPacket bug
« Reply #7 on: March 03, 2005, 11:56:12 PM »
The * is the dereference operator, but it is also the multiplication operator and is also used to designate a pointer.  When you say "operator" that has a specific meaning in C++, and it is more than pedantics to say that because you can overload operators to change their behavior, but not things that aren't operators.  Example of what I mean:
Code: [Select]
int a = 5 & 3; //bitwise AND operator
int* p = &a; //address-of operator
int& r( p ); //declaration of reference to integer named r (NOT an operator)

a = 2 * 3; //mult operator
a = *p; //dereference operator
int* ptr = &a; //declaration of pointer to integer named ptr (NOT an operator).
Gillius
Gillius's Programming http://www.gillius.org/

Gillius

  • Administrator
  • User
  • *****
  • Posts: 147
    • http://www.gillius.org/
CustomPacket bug
« Reply #8 on: March 05, 2005, 08:11:36 PM »
OK, I have clarified the documentation in the CVS.
Gillius
Gillius's Programming http://www.gillius.org/