macOS Cocoa alternative to memcpy()

[Yegg]

Does Cocoa have a true alternative to C's memcpy()?

Where I can do:

unsigned char buf[4];
int x = 1;
	
memcpy (buf, &x, 4);

and this data would be read as the following binary data: "\x01\x00\x00\x00" (if viewed in a standard hex editor).

What needs to be done for Cocoa to produce this same task?

 

[Catfish_Man]

Just use memcpy, what's wrong with it?

 

[Yegg]

Just use memcpy, what's wrong with it?

The question doesn't regard what is wrong with memcpy(). I'd like to stick almost entirely to Cocoa framework in regards to the code I use since most of it will end up being Cocoa anyway. So if Cocoa has it's own alternative to memcpy() (which it sort of seems to, but I can't seem to get it to work how I'd like it to) then I'd rather use that.

Edit: Not sure why I didn't try this right away, but here is the solution:

int x = 1;

NSData *data = [NSData dataWithBytes:&x length:4];

 

[kainjow]

I think it's preferred to use NSValue in these types of instances where you know the data type, but I could be wrong (anyone else know?).

For example:

int x = 1;

NSValue *intValue = [NSValue valueWithBytes:&x objCType:@encode(int)];

 

[lee1210]

Just out of curiosity, what is the goal here? What are you going to do with these "raw bytes"? Even if there is a cocoa-ish way to do this, it's probably best to ensure that you actually need to do it. Is this for debugging?

I've always relied on pointer casting for this sort of thing, because you don't need to do copies, have new memory, etc. and as the original data changes your pointer of a different type will reflect that... i.e.:

#include <stdio.h>

int main(int argc,char *argv[]) {
  int x = 7;
  unsigned char *charView = (unsigned char *)&x;
  printf("Byte 1: %d\nByte 2: %d\nByte 3: %d\nByte 4: %d\n\n",charView[0],charView[1],charView[2],charView[3]);
  x = 12345;
  printf("Byte 1: %d\nByte 2: %d\nByte 3: %d\nByte 4: %d\n\n",charView[0],charView[1],charView[2],charView[3]);
  x = 12345098;
  printf("Byte 1: %d\nByte 2: %d\nByte 3: %d\nByte 4: %d\n\n",charView[0],charView[1],charView[2],charView[3]);
  return 0;
}

On big-endian hardware, this yields:
Byte 1: 7
Byte 2: 0
Byte 3: 0
Byte 4: 0

Byte 1: 57
Byte 2: 48
Byte 3: 0
Byte 4: 0

Byte 1: 10
Byte 2: 95
Byte 3: 188
Byte 4: 0

I mention this specifically in case you are using this for debugging, because this can make things a lot easier. You don't have to do a copy every time you want to print the "new" value of something.

Also, whatever you're doing and however you choose to do it, make sure that it's endian-independent. When you start dealing with raw bytes that can really bite you.

-Lee

 

[Yegg]

These "raw bytes" are getting sent over a socket stream. The server that my code will be communicating with has a proprietary protocol to follow.

Update: At some point the program I am working on will include a section that debugs incoming packets from the server, but I'm already aware of the info you provided me. Thanks though .

I think it's preferred to use NSValue in these types of instances where you know the data type, but I could be wrong (anyone else know?).

For example:

int x = 1;

NSValue *intValue = [NSValue valueWithBytes:&x objCType:@encode(int)];

NSData has more capabilities than NSValue. Not to mention, although the data I am handling will be getting sent over a socket, it is at the same time going to be written to a file on the client-side. NSData provides a method to write the data to a file, while NSValue would require me to use more code to achieve this.

 

[gnasher729]

These "raw bytes" are getting sent over a socket stream. The server that my code will be communicating with has a proprietary protocol to follow.

Time to start learning C. Is yours the first client that is being written? If not, there is probably source code around for other clients that you can re-use. Re-using code has the advantage that existing code often has years of intensive use and bug fixing, so you better have a real good reason to write your own.

 

[Yegg]

Time to start learning C. Is yours the first client that is being written? If not, there is probably source code around for other clients that you can re-use. Re-using code has the advantage that existing code often has years of intensive use and bug fixing, so you better have a real good reason to write your own.

Sorry, but you have no idea what you're talking about. This code is part of a class one might refer to as a "packet buffer" or "packet builder". Since you seem to know so much then you would know that such a class does not need to do too much. It is not an area that one needs to use someone else's code with. I'd also like to mention that I do know C. As far as the protocol of the server used in question, no one has written it in ObjC or Cocoa. Ever. I also know for a fact that my code will be better than essentially anything out in the public so far.

I'd also like to add that the argument for which you base your post makes it sound ridiculous for almost all software development to continue. Why make OpenOffice? MS Word has been out for years. Why make Windows? Unix has been around for so much longer. Let's just "borrow" their code. See my point?

 

[lee1210]

Sorry, but you have no idea what you're talking about. This code is part of a class one might refer to as a "packet buffer" or "packet builder". Since you seem to know so much then you would know that such a class does not need to do too much. It is not an area that one needs to use someone else's code with. I'd also like to mention that I do know C. As far as the protocol of the server used in question, no one has written it in ObjC or Cocoa. Ever. I also know for a fact that my code will be better than essentially anything out in the public so far.

I'd also like to add that the argument for which you base your post makes it sound ridiculous for almost all software development to continue. Why make OpenOffice? MS Word has been out for years. Why make Windows? Unix has been around for so much longer. Let's just "borrow" their code. See my point?

Check your tone. 4/5 of your posts are on this thread, and you joined yesterday. You were asking for help with very little detail, and people were trying to provide it. gnasher729 has posted about 750x more on these forums than yourself and wasn't trying to insult you, so the retaliatory tone is definitely misplaced.

The most important thing for you to deal with is endianness. Your class should focus on accepting the "stream" of data (one piece of data at a time, if appropriate), switching bytes as needed, then sending the buffered, "network endian" packets to the server, etc. Using NSData or NSValue is fine, but might be unnecessary based on the protocol since you're going to mostly be dealing with the stream of bytes. If the C way of doing things inside your class is appropriate don't abstract them in Cocoa types for no net gain.

I don't mean to be harsh, I hope you stick around and get and provide help going forward, but your attitude just didn't make sense.

-Lee

 

[Yegg]

Without wasting my time on an argument, sorry to sound harsh against gnasher, but I don't think his intro post to me starting off by telling me to go learn C was very appropriate. Especially when he knows nothing about what I know.

I provided little detail because it was a simple issue and just needed a simple, straight-forward answer. I consider myself pretty experienced in network related programming. My issue here just happened to be on an area I'm still new at: Cocoa.

Check your tone. 4/5 of your posts are on this thread, and you joined yesterday. You were asking for help with very little detail, and people were trying to provide it. gnasher729 has posted about 750x more on these forums than yourself and wasn't trying to insult you, so the retaliatory tone is definitely misplaced.

The most important thing for you to deal with is endianness. Your class should focus on accepting the "stream" of data (one piece of data at a time, if appropriate), switching bytes as needed, then sending the buffered, "network endian" packets to the server, etc. Using NSData or NSValue is fine, but might be unnecessary based on the protocol since you're going to mostly be dealing with the stream of bytes. If the C way of doing things inside your class is appropriate don't abstract them in Cocoa types for no net gain.

I don't mean to be harsh, I hope you stick around and get and provide help going forward, but your attitude just didn't make sense.

-Lee