форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"recv/send"
Сообщение от Cker on 19-Окт-02, 22:48  (MSK)
Эти функции в качестве буффера требуют массив символов. А как быть, если я хочу к примеру, чтобы эта функция принимала/передавала переменные типа integer?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: recv/send"
Сообщение от Hurricane_postavil_BSD_i_poka_ne_nastroil_russian on 20-Окт-02, 02:03  (MSK)
>Эти функции в качестве буффера требуют массив символов. А как быть, если >я хочу к примеру, чтобы эта функция принимала/передавала переменные типа 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);
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "RE: recv/send"
	Сообщение от joker on 21-Окт-02, 16:16  (MSK)
	>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;
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: recv/send"
	Сообщение от Huricane_nastroil_russkiy_yazik on 21-Окт-02, 16:21  (MSK)
	>>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.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: recv/send"
	Сообщение от vnp on 23-Окт-02, 12:42  (MSK)
	>>>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.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "RE: recv/send"
	Сообщение от Huricane on 23-Окт-02, 13:12  (MSK)
	>>>>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
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "RE: recv/send"
	Сообщение от Cker on 23-Окт-02, 23:33  (MSK)
	А как быть, если, к примеру, мне надо отправить/получить массив слов: array [1..1000] of Word; - на паскале. ?????
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "RE: recv/send"
	Сообщение от hurricane on 24-Окт-02, 10:44  (MSK)
	>А как быть, если, к примеру, мне надо отправить/получить массив слов: >array [1..1000] of Word; - на паскале. >????? Про паскаль не знаю :( Если массив динамический типа char **, то ты его не передашь никак, я думаю. Можно определить свой тип данных, и шуровать его через сокет, как в си, imho Regards, Vlad
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "RE: recv/send"
	Сообщение от Dvorkin on 29-Окт-02, 17:32  (MSK)
	>>>>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
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "RE: recv/send"
	Сообщение от Hurricane on 29-Окт-02, 17:51  (MSK)
	>>>>>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 Как велик и могучь язык Си ....
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.