I have a mediocre background on C and C socket programming.
For the time being as part of a project I had to check socket programming in Python 3.
I was taking a look at the following example :
https://support.mecademic.com/support/solutions/articles/64000253388-python-example-simple-tcp-ip-socket-client
Regarding the command client.send(bytes(cmd '\0','ascii'))
I understand that if one works with low level data connections like network sockets Python 3 transfers data as byte strings: data type bytes.
All of a sudden I was thinking what how this command would be implemented by a c/c client but I got confused with the encoding/decoding part of the buffers.
Let's take for example the following clients which are based on poco library
https://searchcode.com/codesearch/view/25852263/
In all the examples the buffers are char arrays.
What I'd like to ask is that if someone would like to replace the python client with a c like one of the above, then the sending and receiving part remains the same ?
e.x
int n = ss.sendBytes("hello", 5);
char buffer[256];
n = ss.receiveBytes(buffer, sizeof(buffer));
Meaning that by default the C char arrays are ascii encoded?
Or should before sending the buffer to convert for example the ascii string to byte array as in the following example:
https://www.includehelp.com/c/convert-ascii-string-to-byte-array-in-c.aspx
Accordingly the reception needs any decoding as well ?
CodePudding user response:
Please tell me if I am understanding your question correctly. You are trying to send and receive bytes. If your API takes a char[]
array, then you should not convert the individual characters into bytes.
For example, you would pass "C8ICS33" not "43 38 49 43 53 33 33".
Sometimes in c , API will take a std::uint8_t[]
or std::byte[]
array instead of a character. std::uint8_t
is just an unsigned integer the size of a byte. std::byte is a bit more complex, but usually no one uses them.
So TL;DR: don't convert your char[] to "bytes"
CodePudding user response:
Yes, in C and C the char arrays typically hold ASCII (or UTF-8, which is more or less a backward-compatible superset of ASCII) by default, so there isn’t any need to encode or decode those types of strings.