Эти функции в качестве буффера требуют массив символов. А как быть, если я хочу к примеру, чтобы эта функция принимала/передавала переменные типа integer?
>Эти функции в качестве буффера требуют массив символов. А как быть, если
>я хочу к примеру, чтобы эта функция принимала/передавала переменные типа integer?
>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or FGETS FPRINTF.
You cant send integer pointer to socket, convert to char and send it;ex: fprintf(sock,"VAL=%d",(int)5);
>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>FGETS FPRINTF.а почему ? Это влечёт какую-то опасность??
действительно интересно узнать. Первый раз об этом слышу.>You cant send integer pointer to socket, convert to char and send it;
>ex: fprintf(sock,"VAL=%d",(int)5);
можно объявить
char buf[sizeof(int)];
int *int_buf=new int;
buf=(char*)int_buf;
>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>FGETS FPRINTF.
>
>а почему ? Это влечёт какую-то опасность??
>действительно интересно узнать. Первый раз об этом слышу.
>
>>You cant send integer pointer to socket, convert to char and send it;
>>ex: fprintf(sock,"VAL=%d",(int)5);
>можно объявить
>char buf[sizeof(int)];
>int *int_buf=new int;
>buf=(char*)int_buf;Да передать то можно как угодно :) не суть.
Я имел в виду то, что не надо юзать recv/send - это уже история.Regards,
Vladislav.
>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>FGETS FPRINTF.
>>
>>а почему ? Это влечёт какую-то опасность??
>>действительно интересно узнать. Первый раз об этом слышу.
>>>Да передать то можно как угодно :) не суть.
>Я имел в виду то, что не надо юзать recv/send - это
>уже история.Это в самом деле интересно. До сих пор я сталкивался только
с обратной ситуацией -- don't use read/write (for portability
reasons). Что такого плохого с send/recv?>Regards,
> Vladislav.
>>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>>FGETS FPRINTF.
>>>
>>>а почему ? Это влечёт какую-то опасность??
>>>действительно интересно узнать. Первый раз об этом слышу.
>>>
>
>>Да передать то можно как угодно :) не суть.
>>Я имел в виду то, что не надо юзать recv/send - это
>>уже история.
>
>Это в самом деле интересно. До сих пор я сталкивался только
>с обратной ситуацией -- don't use read/write (for portability
>reasons). Что такого плохого с send/recv?
>
>>Regards,
>> Vladislav.Дыкть, portability не под unix, т.к. под виндой только send/recv можно юзать, а под unixами все портабле. Send/recv галимые функции, старые уже, их использовали раньше, а сокет - это по сути файловый дескриптор, зачем над ним извращаться этими sendами ??? С ними тока жопу морочить.
Regards,
Hurik
А как быть, если, к примеру, мне надо отправить/получить массив слов:
array [1..1000] of Word; - на паскале.
?????
>А как быть, если, к примеру, мне надо отправить/получить массив слов:
>array [1..1000] of Word; - на паскале.
>?????Про паскаль не знаю :(
Если массив динамический типа char **, то ты его не передашь никак, я думаю. Можно определить свой тип данных, и шуровать его через сокет, как в си, imhoRegards,
Vlad
>>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>>FGETS FPRINTF.
а если сокет "сырой", или, например SOCK_PACKET?>>>
>>>а почему ? Это влечёт какую-то опасность??
>>>действительно интересно узнать. Первый раз об этом слышу.
думаю, лучше об этом и не слышать - зря не смущаться. :)>>>
>
>>Да передать то можно как угодно :) не суть.
>>Я имел в виду то, что не надо юзать recv/send - это
>>уже история.
??? :)>
>Это в самом деле интересно. До сих пор я сталкивался только
>с обратной ситуацией -- don't use read/write (for portability
>reasons). Что такого плохого с send/recv?
с ними все отлично, уверяю тебя. :)Честно говоря, сам я не пробовал так делать, как ты - не приходилось.
Однако, замечу...
int recv( int s, void *buf, size_t len, int flags);
аналогично send... void *buf - не просто так.
вообще, гарантия 99% что так ты пошлешь все правильно.
Я когда не знаю - просто пробую. :)
вообще, recv/send понимает конец передачи не по Нулю, а по событию в сокете.
Ему должно быть без разницы, что слать.А, не, простите, делал...
Я загонял чиселки в буфер (побитно) и отсылал их. И ниче... Нормально.
Кстати, именно так и делает ICQ при отсылке/получении сообщения.
Просто надо аккуратно буфер этот разбирать/собирать... Сам понимаешь.>
>>Regards,
>> Vladislav.WBR, Dvorkin
>>>>>First of all: DON'T USE RECIVE/SEND . USER READ \ WRITE or
>>>>>FGETS FPRINTF.
>а если сокет "сырой", или, например SOCK_PACKET?
>
>>>>
>>>>а почему ? Это влечёт какую-то опасность??
>>>>действительно интересно узнать. Первый раз об этом слышу.
>думаю, лучше об этом и не слышать - зря не смущаться. :)
>
>
>>>>
>>
>>>Да передать то можно как угодно :) не суть.
>>>Я имел в виду то, что не надо юзать recv/send - это
>>>уже история.
>??? :)
>
>>
>>Это в самом деле интересно. До сих пор я сталкивался только
>>с обратной ситуацией -- don't use read/write (for portability
>>reasons). Что такого плохого с send/recv?
>с ними все отлично, уверяю тебя. :)
>
>Честно говоря, сам я не пробовал так делать, как ты - не
>приходилось.
>Однако, замечу...
>int recv( int s, void *buf, size_t len, int flags);
>аналогично send... void *buf - не просто так.
>вообще, гарантия 99% что так ты пошлешь все правильно.
>Я когда не знаю - просто пробую. :)
>вообще, recv/send понимает конец передачи не по Нулю, а по событию в
>сокете.
>Ему должно быть без разницы, что слать.
>
>А, не, простите, делал...
>Я загонял чиселки в буфер (побитно) и отсылал их. И ниче... Нормально.
>
>Кстати, именно так и делает ICQ при отсылке/получении сообщения.
>Просто надо аккуратно буфер этот разбирать/собирать... Сам понимаешь.
>
>>
>>>Regards,
>>> Vladislav.
>
>WBR, DvorkinКак велик и могучь язык Си ....