[zeromq-dev] Communication between C++ zmq client and Python zmq Server
Thomas Rodgers
rodgert at twrodgers.com
Mon Feb 5 23:14:50 CET 2018
The problem is spelled out in -
[with _IIter = const char*; _Size = long unsigned int; _OIter = void*]
‘request.data()’ returns void*
‘result.c_str()’ returns const char*
Try using ‘reinterpret_cast<char*>(request.data())’ instead of the bare
‘request.data()’.
On Mon, Feb 5, 2018 at 12:56 PM Bernardo Augusto García Loaiza <
botibagl at gmail.com> wrote:
> Thomas, I test any of two alternatives but my output when I build is :
>
> /usr/include/c++/7/bits/stl_algo.h:806:27: required from ‘_OIter
> std::copy_n(_IIter, _Size, _OIter) [with _IIter = const char*; _Size = long
> unsigned int; _OIter = void*]’
> /home/bgarcial/workspace/sofa/src/applications/plugins/ZeroMQCommunication/ZMQServerComponent.cpp:92:65:
> required from here
> /usr/include/c++/7/bits/stl_iterator_base_types.h:184:43: error: forming
> reference to void
> typedef _Tp& reference;
> ^~~~~~~~~
> applications/plugins/ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/build.make:86:
> recipe for target
> 'applications/plugins/ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/ZMQServerComponent.cpp.o'
> failed
> make[2]: ***
> [applications/plugins/ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/ZMQServerComponent.cpp.o]
> Error 1
> CMakeFiles/Makefile2:10113: recipe for target
> 'applications/plugins/ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/all'
> failed
> make[1]: ***
> [applications/plugins/ZeroMQCommunication/CMakeFiles/ZeroMQCommunication.dir/all]
> Error 2
> Makefile:162: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
> Is possible to this error make reference tto copy_n function return an int
> value and I have inside void function ?
> I've been searched about it, but the samples are in reference to another
> cases more advances using templates and pointers between others ./..
>
>
>
>
> Bernardo Augusto García Loaiza
> Ingeniero de Sistemas
> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
> http://about.me/bgarcial
>
>
> On Wed, Jan 31, 2018 at 11:23 PM, Thomas Rodgers <rodgert at twrodgers.com>
> wrote:
>
>> Correction! Should read -
>>
>> std::copy_n(result.c_str(), result.size() + 1, request.data());
>>
>> OR
>>
>> std::copy_n(result.data(), result.size() + 1, request.data());
>>
>>
>>
>> On Wed, Jan 31, 2018 at 10:18 PM, Thomas Rodgers <rodgert at twrodgers.com>
>> wrote:
>>
>>> Is this correct?
>>>
>>>
>>> Yes
>>>
>>>
>>>> 1. What advantages do I have when using something like protocol buffer
>>>> to serialization data instead of
>>>> send the data of a basic way such as I perform here turn the data to
>>>> string and sending it?
>>>>
>>>
>>> If you want to send complex data structures, portably between different
>>> programming language environments and processor architectures.
>>> This is not a goal of ZeroMQ and is explicitly left to other libraries
>>> and tools.
>>>
>>> | 2. Why use memcpy is bad or not suited?
>>>
>>> http://en.cppreference.com/w/cpp/algorithm/copy
>>> http://en.cppreference.com/w/cpp/algorithm/copy_n
>>>
>>> are better alternatives in C++ and as, or more efficient than ::memcpy
>>> (they in fact delegate, as inline code to ::memcpy if that is the fastest
>>> way to perform the copy).
>>>
>>> your example would read -
>>>
>>> #include <algorithm>
>>>
>>> ...
>>>
>>> std::copy_n(request.data(), result.size(), result.c_str());
>>>
>>> OR
>>>
>>> std::copy_n(request.data(), result.size(), result.begin());
>>>
>>> On Wed, Jan 31, 2018 at 12:33 PM, Bernardo Augusto García Loaiza <
>>> botibagl at gmail.com> wrote:
>>>
>>>> Hi Thomas, thanks for your appreciations
>>>>
>>>> In the memcpy function in the second parameter named const void *
>>>> source ...
>>>>
>>>> void * memcpy ( void * destination, const void * source, size_t num );
>>>>
>>>>
>>>> the c_strt() function is suited place here because this return a
>>>> pointer to the variable value
>>>>
>>>> Is this correct?
>>>>
>>>> [image: Inline image 1]
>>>>
>>>> I am C++ and ZMQ newbie, although is a great idea measure dynamically
>>>> the size of the request
>>>> in the moment of send the data via zmq such as you tell me.
>>>>
>>>> According to this, the data is sent to my server and I can visualize
>>>> your content of a suited way.
>>>>
>>>> I have two questions:
>>>>
>>>>
>>>> 1. What advantages do I have when using something like protocol buffer
>>>> to serialization data instead of
>>>> send the data of a basic way such as I perform here turn the data to
>>>> string and sending it?
>>>>
>>>> I've been check inside the zmq documentations about it
>>>> <http://zguide.zeromq.org/page:all#Serializing-Your-Data>, but I don't
>>>> have clear if serialization
>>>> in first instance is necessary or which the advantages and against
>>>>
>>>>
>>>> 2. Why use memcpy is bad or not suited?
>>>> I've been read about it, and I found ...
>>>>
>>>> memcpy copies a block of raw memory from one location to another ...
>>>> Several of the inconvenient are (basically it's a copy/paste from some
>>>> links):
>>>>
>>>> - Overlapping source and destination buffers: The behaviour of
>>>> memcpy is undefined if the source and destination buffers overlap
>>>>
>>>> How to could overlap the source and destination buffers in one zmq
>>>> operation? Is right think in this question?
>>>>
>>>>
>>>>
>>>> - Maintaining alignment
>>>>
>>>> Data types such as integers and floating point numbers are often
>>>> subject to an alignment constraint that limits where they can be placed in
>>>> memory. For example, 4-byte integers must often be placed at an address
>>>> that is a multiple of 4 bytes. Normally the compiler would ensure that
>>>> alignment constraints are respected, but using memcpy it is possible to
>>>> copy an object to a misaligned address
>>>>
>>>> In other site, I found this about of bandwidth demand copying things:
>>>>
>>>> There is nothing wrong with memcpy, except that it takes a long time.
>>>> Excessive use of memory copying is sometimes a sign of poor program
>>>> design.
>>>> In a real-time system, it may be outright unacceptable. For example, if
>>>> you
>>>> copy the entire packet data at each layer transition in a protocol
>>>> stack, you
>>>> may find that your stack cannot handle as high a bandwidth as it
>>>> otherweise
>>>> could, thereby failing to meet requirements.
>>>>
>>>> In some lectures talk about of use memmove() instead of memcpy, in
>>>> relation to buffer overlapping ...
>>>>
>>>> In the context of performance and data transport via zmq, wha is the
>>>> recommended option to
>>>> use instead of memcpy
>>>>
>>>> Because zeromq in their website documentation samples, use memcpy
>>>> <http://zguide.zeromq.org/cpp:hwserver> ?
>>>> Is this a old version to work witn zmq to connect to socket and send
>>>> data?
>>>>
>>>> Thanks for all your orientation about it.
>>>> Best Regards
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Bernardo Augusto García Loaiza
>>>> Ingeniero de Sistemas
>>>> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
>>>> http://about.me/bgarcial
>>>>
>>>>
>>>> On Tue, Jan 30, 2018 at 6:13 PM, Thomas Rodgers <rodgert at twrodgers.com>
>>>> wrote:
>>>>
>>>>> You can’t memcpy a std::string, and in fact, you should t be using
>>>>> memcpy in general in C++. I won’t go into the why of all of that here, but
>>>>> start by changing -
>>>>>
>>>>> memcpy(request.data(), *&result*, 30);
>>>>>
>>>>> To
>>>>>
>>>>> memcpy(request.data(), *result.c_str()*, result.size() + 1);
>>>>>
>>>>>
>>>>> On Tue, Jan 30, 2018 at 4:46 PM Bernardo Augusto García Loaiza <
>>>>> botibagl at gmail.com> wrote:
>>>>>
>>>>>> Hi, I again.
>>>>>>
>>>>>> I've performed some small test in relation to the way on how to I
>>>>>> sending the data member structure.
>>>>>>
>>>>>> I am turning the int data member structure to string before to be
>>>>>> send it ..
>>>>>> In the following code section I am turn btnState in string data and
>>>>>> assign it to string s variable and I contatenated it some additional string
>>>>>> content and
>>>>>> I sending this string concatenated result:
>>>>>>
>>>>>> void ZMQComponent::instrumentDataSend(instrumentData a){
>>>>>> /* Initialize the data members structure instrumentData */
>>>>>> a.pos = sofa::defaulttype::Vec3d(1.0f, 1.0f, 1.0f);
>>>>>> a.quat = defaulttype::Quat(1.0f, 1.0f, 4.0f, 1.0f);
>>>>>> a.btnState = 5671;
>>>>>> a.openInst = 1.0f;
>>>>>> a.blnDataReady = false;
>>>>>>
>>>>>>
>>>>>>
>>>>>> * string s, test, result, d;
>>>>>> s = to_string(a.btnState);
>>>>>> test = " is a number";
>>>>>> result = s + test;*
>>>>>>
>>>>>>
>>>>>>
>>>>>> /* We send the btnState data */
>>>>>>
>>>>>>
>>>>>> zmq::message_t request(30);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> /* We ask for the memory address to ge the btnState content and send it. */
>>>>>>
>>>>>>
>>>>>> memcpy(request.data(), *&result*, 30);
>>>>>> socket.send(request);}
>>>>>>
>>>>>>
>>>>>> The output or the message which arrive to python zmq server is the
>>>>>> content of
>>>>>> result variable (btnState turn to string in s content variable +
>>>>>> string test concatenated)
>>>>>> and some symbols characters of the :
>>>>>>
>>>>>> (cnvss_test) ➜ Python git:(ZMQCommunication) ✗ python server.py
>>>>>> ZMQ Server listening ...
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180205/c5b7d492/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 52201 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180205/c5b7d492/attachment.png>
More information about the zeromq-dev
mailing list