---

std::cout<<"Godaften/nat"<<endl;

Jeg sidder i FreeBSD og skriver nogle netværksprogrammer, men er begyndt
at bruge strings fremfor char *'s. Problemet ligger i kald som read og
write.
Til write() kan jeg bare bruge "string.c_str", men ved store strings må
dette da give en del overhead, så er der en anden løsning her?
read() ved jeg ikke hvordan jeg skal overkomme, den vil hverken have
strings eller string.c_str (forståeligt nok).

Håber nogen herind kan hjælpe.

mvh
db

ps: Jeg kan vel godt bruge:
   string adresse;
   cin>>adresse;
   inet_addr(@adresse[0]);

---

On Thu, 19 Sep 2002 02:45:31 +0200, Socketd wrote:

> ps: Jeg kan vel godt bruge:
>    string adresse;
>    cin>>adresse;
>    inet_addr(@adresse[0]);

ups @adresse[0] = &adresse[0];

mvh
db

---

"Socketd" <db@traceroute.dk> wrote in message
news:pan.2002.09.18.23.45.30.640197.270@traceroute.dk...
> std::cout<<"Godaften/nat"<<endl;

Det skal være:
std::cout<<"Godaften/nat"<<std::endl;

> Jeg sidder i FreeBSD og skriver nogle netværksprogrammer, men er begyndt
> at bruge strings fremfor char *'s. Problemet ligger i kald som read og
> write.
> Til write() kan jeg bare bruge "string.c_str", men ved store strings må
> dette da give en del overhead, så er der en anden løsning her?

Hvorfor tror du det? Det afhænger selvfølgelig af implementationen, men
normalt implementeres std::string som et dynamisk allokeret array, så
std::string::c_str() returnerer bare en pointer til den interne
representation.

> read() ved jeg ikke hvordan jeg skal overkomme, den vil hverken have
> strings eller string.c_str (forståeligt nok).

Hvis du absolut vil bruge read(), bliver du nødt til at læse ind i en char[]
og kopiere data over i en std::string bagefter. Jeg forstår dog ikke hvorfor
du vil bruge read() og write().

Ivan Johansen

---

On Thu, 19 Sep 2002 12:17:18 +0200, Ivan Johansen wrote:
>> std::cout<<"Godaften/nat"<<endl;
>
> Det skal være:
> std::cout<<"Godaften/nat"<<std::endl;

.....

>> Jeg sidder i FreeBSD og skriver nogle netværksprogrammer, men er
>> begyndt at bruge strings fremfor char *'s. Problemet ligger i kald som
>> read og write.
>> Til write() kan jeg bare bruge "string.c_str", men ved store strings må
>> dette da give en del overhead, så er der en anden løsning her?
>
> Hvorfor tror du det? Det afhænger selvfølgelig af implementationen, men
> normalt implementeres std::string som et dynamisk allokeret array, så
> std::string::c_str() returnerer bare en pointer til den interne
> representation.

Ok, jeg troede den returneret en char *.

> Hvis du absolut vil bruge read(), bliver du nødt til at læse ind i en
> char[] og kopiere data over i en std::string bagefter. Jeg forstår dog
> ikke hvorfor du vil bruge read() og write().

Hvad skal jeg ellers bruge til at skrive til og læse fra en socket?

mvh
db

---

"Socketd" <db@traceroute.dk> wrote in message
news:pan.2002.09.19.09.37.54.42959.199@traceroute.dk...
> On Thu, 19 Sep 2002 12:17:18 +0200, Ivan Johansen wrote:
> Ok, jeg troede den returneret en char *.

Den returnerer en const char*. Hvis du kigger ind i funktionen ser den ofte
sådan ud eller lignende:
return data_;

Så den returnerer bare pointeren data_, hvilket ikke giver noget overhead.
Men det afhænger af implementation.

> Hvad skal jeg ellers bruge til at skrive til og læse fra en socket?

Åh vi snakker sockets. Det burde kunne gøres bedre, men jeg ved desværre
ikke hvordan. Jeg har ikke gjort meget i sockets.

Ivan Johansen

---

On Thu, 19 Sep 2002 13:41:53 +0200, Ivan Johansen wrote:
> Den returnerer en const char*. Hvis du kigger ind i funktionen ser den
> ofte sådan ud eller lignende:
> return data_;
>
> Så den returnerer bare pointeren data_, hvilket ikke giver noget
> overhead. Men det afhænger af implementation.

Fino*S*

>> Hvad skal jeg ellers bruge til at skrive til og læse fra en socket?
>
> Åh vi snakker sockets. Det burde kunne gøres bedre, men jeg ved desværre
> ikke hvordan. Jeg har ikke gjort meget i sockets.

Ups ja, jeg burde nok lige have forklaret at det var sockets, til filer
bruger jeg ikke read() og write(), men ved socket er der ingen vej udenom
de to nævnte funktioner(?!?).

mvh
db

---

"Ivan Johansen" <NG@Padowan.dk> wrote in message
news:<3d899626$0$75635$edfadb0f@dspool01.news.tele.dk>...

> Hvis du absolut vil bruge read(), bliver du nødt til at læse ind i en
> char[] og kopiere data over i en std::string bagefter.

Hvis mængden af data, der læses først kendes på runtime, kan man med fordel
anvende en std::vector<char>, som f.eks.

void foo()
{
// ...
vector<char> buffer(bytes_to_read);
some_c_read_func(&buffer[0], bytes_to_read);
// ...
}

Se eventuelt også frameworket ACE (http://siesta.cs.wustl.edu/~schmidt/),
hvor der findes en mængde nyttig funktionalitet til socket programmering.

Venlig hilsen

Mogens Hansen

---

[ db@traceroute.dk ]

[ ... ]

> Til write() kan jeg bare bruge "string.c_str", men ved store strings
> må dette da give en del overhead, så er der en anden løsning her?


For det første vil ikke std::string::c_str fungere (pga. '\0'-byte
håndtering). For det andre er det feil å bruke read og write til
socket kommunikasjon i C++ (man har streams til sånt). For det tredje
er det utelukkende defekte implementasjoner som ikke makter å
implementere std::string::data/c_str i O(1).

Det du egentlig vil er å lage din egen stream buffer som tar seg av
nettverkskommunikasjon. Således vil ikke std::string socket I/O være
noe annerledes enn "vanlig fil I/O".

Boken til Langer && Kreft inneholder alle de interessante detaljene.

[ ... ]


> ps: Jeg kan vel godt bruge:
>    string adresse;
>    cin>>adresse;
>    inet_addr(@adresse[0]);


Takler inet_addr ikke '\0'-terminerte tekster?





ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
            -- pederst på irc

---

On Thu, 19 Sep 2002 16:13:02 +0200, Igor V. Rafienko wrote:
>> Til write() kan jeg bare bruge "string.c_str", men ved store strings må
>> dette da give en del overhead, så er der en anden løsning her?
>
>
> For det første vil ikke std::string::c_str fungere (pga. '\0'-byte
> håndtering). For det andre er det feil å bruke read og write til socket
> kommunikasjon i C++ (man har streams til sånt). For det tredje er det
> utelukkende defekte implementasjoner som ikke makter å implementere
> std::string::data/c_str i O(1).

> Det du egentlig vil er å lage din egen stream buffer som tar seg av
> nettverkskommunikasjon. Således vil ikke std::string socket I/O være noe
> annerledes enn "vanlig fil I/O".

Ok, nogen eksempler på hvordan jeg skal gøre det? Altså socket
programmering uden read() og write()?


> Boken til Langer && Kreft inneholder alle de interessante detaljene.

En gang til?

>>ps: Jeg kan vel godt bruge:
>>    string adresse;
>>    cin>>adresse;
>>    inet_addr(@adresse[0]);
>
>
> Takler inet_addr ikke '\0'-terminerte tekster?

Ved det ikke, men vil følgende så ikke virke? &adresse[0].c_str

mvh
db

---

[ db@traceroute.dk ]

[ ... ]


> Ok, nogen eksempler på hvordan jeg skal gøre det? Altså socket
> programmering uden read() og write()?


Du er naturligvis nødt til å bruke read/write fra det underliggende
OSet i stream buffer *implementasjonen*, men det er igrunn det eneste
stedet der man ikke slipper unna. C++ applikasjonskoden trenger aldri
å bry seg om disse funksjonene.


> > Boken til Langer && Kreft inneholder alle de interessante
> > detaljene.
>
> En gang til?


ISBN 0201183951

[ ... ]


> Ved det ikke, men vil følgende så ikke virke? &adresse[0].c_str


Problemet er at c_str behandler C-style strings. Der brukes '\0' for å
betegne slutten av teksten, noe som er _uhyre_ idiotisk i alle
tenkelige kontekster siden hukommelsen er sluttet å bli astronomisk
dyr (i god tid før jeg ble født, tipper jeg). std::string kan godt
inneholde '\0'-bytes i seg, og nettopp da vil man få problemer dersom
man velger å bruke c_str for å "konvertere" en std::string til en
const char*.

Med nød vil man ha std::string::data(), men aller helst vil man skrive
en abstraksjon som tillater å gjøre std::getline() og op<<() på
network "streams" på lik linje med file streams. Og da vil man kunne
gjøre noe sånt:

using namespace std;
itcpstream its( "www.somehost.net", SOURCE_PORT );
if ( !its )
exit( 1 );

std::string line;
while ( getline( its, buffer ) )
process( line );

.... noe som er identisk med en filløsning.

(Dog, for å være helt rettferdig må det sies at C++ IO streams har
read/write kall. Og de er _like_ hjerneskadede som read/write i
*nix-aktig C omgivelse. Men det er ingenting som forhindrer en fra å
fx. bruke stream iterators. Dessverre blir man kanskje nødt til å
jobbe litt for å få det til å gå fort).





ivr
--
<peder> igorr: tcl ja... det er fra de dypeste avgrunnene i helvete det...
<peder> php er bare fra foajeen
            -- pederst på irc

---

On Thu, 19 Sep 2002 19:36:34 +0200, Igor V. Rafienko wrote:

> Du er naturligvis nødt til å bruke read/write fra det underliggende OSet
> i stream buffer *implementasjonen*, men det er igrunn det eneste stedet
> der man ikke slipper unna. C++ applikasjonskoden trenger aldri å bry seg
> om disse funksjonene.

oki

> Problemet er at c_str behandler C-style strings. Der brukes '\0' for å
> betegne slutten av teksten, noe som er _uhyre_ idiotisk i alle tenkelige
> kontekster siden hukommelsen er sluttet å bli astronomisk dyr (i god tid
> før jeg ble født, tipper jeg). std::string kan godt inneholde '\0'-bytes
> i seg, og nettopp da vil man få problemer dersom man velger å bruke
> c_str for å "konvertere" en std::string til en const char*.
>
> Med nød vil man ha std::string::data(), men aller helst vil man skrive
> en abstraksjon som tillater å gjøre std::getline() og op<<() på network
> "streams" på lik linje med file streams. Og da vil man kunne gjøre noe
> sånt:
>
> using namespace std;
> itcpstream its( "www.somehost.net", SOURCE_PORT ); if ( !its )
> exit( 1 );
>
> std::string line;
> while ( getline( its, buffer ) )
> process( line );
>
> ... noe som er identisk med en filløsning.
>
> (Dog, for å være helt rettferdig må det sies at C++ IO streams har
> read/write kall. Og de er _like_ hjerneskadede som read/write i
> *nix-aktig C omgivelse. Men det er ingenting som forhindrer en fra å fx.
> bruke stream iterators. Dessverre blir man kanskje nødt til å jobbe litt
> for å få det til å gå fort).

ok, takker for svaret

mvh
db