Forum Debian Users Gang

Huk · 2012-09-30 09:52:45

Witam.

Szukam, szukam ale coś znaleźć nie mogę. Mam taki problem - przekierowuje sobie cout'a w taki sposób aby móc go odczytać wewnątrz programu. Wszystko działa OK... program wygląda tak:

Kod:

#include <iostream>
#include <unistd.h>
#include <fcntl.h>
#include <cstdlib>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
using namespace std;
 
int main()
{
    int bufSize=100;
    
    char buf[bufSize];
    int x[2];
    
    /* Potrzebny nam numer stdout */
    int stdout_num = fileno(stdout);

    /* Kopiujemy deskryptor; będzie nam potrzebny później */
    int stdout_fd = dup(stdout_num);
    
    memset(buf,0,bufSize);    
    
    pipe(x);
    dup2(x[1],fileno(stdout));
    
    if(fork()==0)
    {
        cout << "ABCD" << "\n" << flush;
    }
          else
          {
              read(x[0],buf,bufSize);    
              dup2(stdout_fd, stdout_num);
    
              printf("%s",buf);
          }    
    return 0;
}//end of function main

No i tutaj zaczynają się jajka - nie wiem czy dobrze myślę, w C specem nie jestem - ale chyba dobrą praktyką była by alokacja takiego bufora jaką wielkość ma wiadomość przesłana do cout... pytanie jak to DOBRZE zrobić? Czy da się jakoś pobrać wielkość buffora wykorzystywanego do przechowywania tego co wpada do cout, czy też trzeba iterować na zasadzie:

Kod:

int i=0;
char znak;
        
do
{
    read(x[0],&znak,1);
    ++i;
}
while(znak!='\n');

Nie ma żadnego ładniejszego sposobu? Prośba o info od szpeców od C :)

Pozdro.

Ostatnio edytowany przez Huk (2012-09-30 09:56:10)

djjanek · 2012-09-30 11:11:00

Specjalistą też nie jestem ale string.h chyba należy do C++, a jak już go wykorzystujesz to ja bym zrobił zapisywanie do zmiennej string i się nie męczył z odczytywaniem. Jak dobrze pamiętam w string na pozycji 0 masz ile znaków ma string. dodatkowo nie powinni być:

Kod:

...      
do
{
    read(x[i],&znak,1);
    ++i;
}
...

Ostatnio edytowany przez djjanek (2012-09-30 11:11:40)

Huk · 2012-09-30 11:28:38

@djjanek:

Ojj sorry nie patrz na nagłówki do końca, to programik strasznie rozwalony na którym testuję mieszankę - stąd tam nagłówki C++ są. W realnej aplikacji ma być czysty C - C++ wykluczony.

Pozdro.

marc · 2012-10-02 01:50:00

Nie tylko string nalezy do C++. Cout, etc to C++. C to printf, scanf, etc. C++ jest nabudowane na C, ale wiele rzeczy sie rozni. W jakim jezyku ostatecznie piszesz?

Huk · 2012-10-02 06:19:01

@marc:

Ja to wiem, wierz mi ;] programik który był zamieszczony to zlepek C i C++ (a wcześniej jeszcze QT), ale cała sprawa rozchodzi się o to jak to robić w czystym C.

Pozdro.

marc · 2012-10-02 10:31:29

Aha, to pardon moi ;) tak sie po prostu zdziwilem troche, bo sam kiedys programowalem w C++, dzis w C [ale nie jestem ekspertem, a hobbysta].

Piotr3ks · 2012-10-02 18:57:58

Moim zdaniem tutaj nie ma zbytniego sensu żeby alokować dynamicznie bufor, bo:
- pipe jest ograniczony i tak przez system

Kod:

$ ulimit -a | grep "pipe size"
pipe size            (512 bytes, -p) 8

- nie da się jednoznacznie sprawdzić wielkości danych z pipe'a bez ich odczytania

Huk · 2012-10-03 07:55:32

@Piotr3ks:

No właśnie o to mi chodzi. Generalnie zastanawiam się po prostu, jak pisać programy w C - skoro wszystko trzeba robić ręcznie.

Realnie chodzi o to że w swoim śmiesznym pluginie do ALSY, muszę zaczytać to co wypluje komenda:

Kod:

lsof -F p /dev/snd/pcmC0D0p

Raz powyższe zwróci 0, raz 8 a raz 120 znaków - no i pytanie o dobre praktyki przy zaczytywaniu tego. W C++ robimy to dynamicznie i problemu nie ma, ale w C trzeba zaalokować pamięć i robią się jajka, bo albo robię "na pałę" jakiś buffor w stylu:

Kod:

char commandOutput[1024];

Co IMHO - z punktu widzenia programisty C++ - jest "bee", bo zawsze może się przepełnić. Albo dwa razy czytam tego samego pipe'a - raz do ustalenia wielkości, raz do zaczytania realnej zawartości. Pytanie które jest uważane przez programistów C, za dobrą praktykę? Jak dla mnie oba powyższe są do kitu, stąd pytanie, więc może jest jeszcze jakieś podejście lepsze? :)

Pozdro.

milyges · 2012-10-03 09:20:38

Alokujesz bufor np. na 1024, czytasz 1024 znaki do niego, jeżeli odczytałeś równe 1024, robisz realloc() + 1024, czytasz znów 1024 bajty do bufora przesuniętego od poczatku o 1024, i tak w pętli poza krokiem 1 ;)
Pozdro

HAL9000 · 2012-10-03 18:23:58

Opis pojemników Qt, w paragrafie "Growth Strategies" jest coś do poczytania na temat realokacji
http://qt-project.org/doc/qt-4.8/containers.html

Time (s)	Query
0.00010	SET CHARSET latin2
0.00005	SET NAMES latin2
0.00134	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.117.166.193' WHERE u.id=1
0.00085	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.117.166.193', 1732419369)
0.00038	SELECT * FROM punbb_online WHERE logged<1732419069
0.00066	DELETE FROM punbb_online WHERE ident='3.137.173.98'
0.00043	SELECT topic_id FROM punbb_posts WHERE id=212029
0.00004	SELECT id FROM punbb_posts WHERE topic_id=22072 ORDER BY posted
0.00069	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=22072 AND t.moved_to IS NULL
0.00005	SELECT search_for, replace_with FROM punbb_censoring
0.00146	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=22072 ORDER BY p.id LIMIT 0,25
0.00078	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=22072
Total query time: 0.00683 s

Forum Debian Users Gang

Ogłoszenie

#1 2012-09-30 09:52:45

Huk - Smoleńsk BULWA!

C - jakie są dobre praktyki odnosnie alokacji buforów?

Kod:

Kod:

#2 2012-09-30 11:11:00

djjanek - Użytkownik

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

Kod:

#3 2012-09-30 11:28:38

Huk - Smoleńsk BULWA!

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

#4 2012-10-02 01:50:00

marc - Użytkownik

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

#5 2012-10-02 06:19:01

Huk - Smoleńsk BULWA!

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

#6 2012-10-02 10:31:29

marc - Użytkownik

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

#7 2012-10-02 18:57:58

Piotr3ks - Też człowiek :-)

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

Kod:

#8 2012-10-03 07:55:32

Huk - Smoleńsk BULWA!

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

Kod:

Kod:

#9 2012-10-03 09:20:38

milyges - inż.

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

#10 2012-10-03 18:23:58

HAL9000 - Użytkownik

Re: C - jakie są dobre praktyki odnosnie alokacji buforów?

Stopka forum

Informacje debugowania