macOS Cocoa alternative to memcpy()

Yegg · Apr 17, 2009

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

Where I can do:

Code:

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 · Apr 17, 2009

Just use memcpy, what's wrong with it?

Yegg · Apr 17, 2009

Catfish_Man said:
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:

Code:

int x = 1;

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

kainjow · Apr 17, 2009

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:

Code:

int x = 1;

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

lee1210 · Apr 17, 2009

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.:

Code:

#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 · Apr 17, 2009

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

.

kainjow said:
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:

Code:

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 · Apr 18, 2009

Yegg said:
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 · Apr 18, 2009

gnasher729 said:
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 · Apr 18, 2009

Yegg said:
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 · Apr 18, 2009

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.

lee1210 said:
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

Search

Search

macOS Cocoa alternative to memcpy()

Yegg

macrumors newbie

Catfish_Man

macrumors 68030

Yegg

macrumors newbie

kainjow

Moderator emeritus

lee1210

macrumors 68040

Yegg

macrumors newbie

gnasher729

Suspended

Yegg

macrumors newbie

lee1210

macrumors 68040

Yegg

macrumors newbie

Our Staff