stream -> iobuf*

**Alf P. Steinbach** · Jun 27 '08, 04:37 PM

Re: stream -> iobuf*

* Jim Langston:

Is it possible in C++ to create some type of stream and pass something as
an iobuf* such that fprintf uses?

'iobuf' is not a standard type (i.e., it's environment-specific).

The reason is I am using some libraries that write to an open file pointer,
but I want to use the data in my program without having to change the
library source (all written in c).

The description is a bit vague.

Depends what you want, but if you want to avoid disk access you might use a
memory mapped file. At the C++ stream level there's some support in Boost, as I
recall. At the C FILE* level I don't know, but surely something can be
arranged, although necessarily in a more or less environment specific manner.

Cheers, & hth.,

- Alf

**Jim Langston** · Jun 27 '08, 04:37 PM

Re: stream -> iobuf*

Alf P. Steinbach wrote:

* Jim Langston:

> Is it possible in C++ to create some type of stream and pass
>something as an iobuf* such that fprintf uses?

>
'iobuf' is not a standard type (i.e., it's environment-specific).
>
>

>The reason is I am using some libraries that write to an open file
>pointer, but I want to use the data in my program without having to
>change the library source (all written in c).

>
The description is a bit vague.
>
Depends what you want, but if you want to avoid disk access you might
use a memory mapped file. At the C++ stream level there's some
support in Boost, as I recall. At the C FILE* level I don't know,
but surely something can be arranged, although necessarily in a more
or less environment specific manner.

I just checked the Boost documentation online and didn't see anything that
would do it for me. Let me explain what I am wanting to do.

I am writing a program and it has some node type informatoin which I wish to
represent in a certain way. Looking around I found dot which text output
gives me exactly what I need for the data input. I downloaded the source
code and spent a day compiling it searching for the dependancies, getting
environment set up correctly, etc...

The program dot accepts input from a few methods, file, stdin for sure,
maybe memory. That I don't think I'll have too much trouble with although I
might. The real problem is the output. The output writes to stdout, a file
and looking through the docs into memory, except the memory portion doesn't
work for a few reasons. For one it leaks memory by allocating memory to a
pointer using malloc in a lib which can't be freed from the exe, doesn't
have a method to free it and doesn't allocate enough memory to begin. :Then
when it is used it tries to write to a FILE* which isn't created anyway and
crashes.

The source for thsi library, graphviz 2.18, is written in C, which is not
suprising considering it's apparent age, and is quite large, 1168 .c files
taking up 13,906,836 bytes. And that's not couting the headers. And it
does nasty things like having external global variables, etc.... To debug
and fix this will be quite a chore.

Well, what does work is stdin, stdout and fileio. So what I was hoping was
to be able to wrap dot in a class where I could pass it a memory block
loaded with the data to process (most likely contained in a std::vector),
have it call the libraries and catch either the file out put or stdout
output and return it to the program. Since it's C and not C++ it uses
stdout not std::cout so redirecting std::out's buffer isn't going to do me
much good.

I've been googling all day trying to find some method. The closest I've
found is some documentation talking about some VME low level driver
http://www.n4comm.com/utogenf.htm I think that if I created some type of
driver that caught the file output and kept it in a buffer that might be
workable, but will take me some time to develop (havn't written any drivers
yet would take some reasearch).

If nothing is doable I'll wind up hacking all the source code to get it to
work throwing away large portions of graphviz in the process as what I
implement breaks other things I have no need for at this time, but may in
the future. I don't like changing library source code when I don't have to.

--
Jim Langston
tazmaster@rocke tmail.com

**Alf P. Steinbach** · Jun 27 '08, 04:37 PM

Re: stream -> iobuf*

* Jim Langston:

Alf P. Steinbach wrote:

>* Jim Langston:

>> Is it possible in C++ to create some type of stream and pass
>>something as an iobuf* such that fprintf uses?

>'iobuf' is not a standard type (i.e., it's environment-specific).
>>
>>

>>The reason is I am using some libraries that write to an open file
>>pointer, but I want to use the data in my program without having to
>>change the library source (all written in c).

>The description is a bit vague.
>>
>Depends what you want, but if you want to avoid disk access you might
>use a memory mapped file. At the C++ stream level there's some
>support in Boost, as I recall. At the C FILE* level I don't know,
>but surely something can be arranged, although necessarily in a more
>or less environment specific manner.

>
I just checked the Boost documentation online and didn't see anything that
would do it for me. Let me explain what I am wanting to do.
>
I am writing a program and it has some node type informatoin which I wish to
represent in a certain way. Looking around I found dot which text output
gives me exactly what I need for the data input. I downloaded the source
code and spent a day compiling it searching for the dependancies, getting
environment set up correctly, etc...
>
The program dot accepts input from a few methods, file, stdin for sure,
maybe memory. That I don't think I'll have too much trouble with although I
might. The real problem is the output. The output writes to stdout, a file
and looking through the docs into memory, except the memory portion doesn't
work for a few reasons. For one it leaks memory by allocating memory to a
pointer using malloc in a lib which can't be freed from the exe, doesn't
have a method to free it and doesn't allocate enough memory to begin. :Then
when it is used it tries to write to a FILE* which isn't created anyway and
crashes.
>
The source for thsi library, graphviz 2.18, is written in C, which is not
suprising considering it's apparent age, and is quite large, 1168 .c files
taking up 13,906,836 bytes. And that's not couting the headers. And it
does nasty things like having external global variables, etc.... To debug
and fix this will be quite a chore.
>
Well, what does work is stdin, stdout and fileio. So what I was hoping was
to be able to wrap dot in a class where I could pass it a memory block
loaded with the data to process (most likely contained in a std::vector),
have it call the libraries and catch either the file out put or stdout
output and return it to the program. Since it's C and not C++ it uses
stdout not std::cout so redirecting std::out's buffer isn't going to do me
much good.
>
I've been googling all day trying to find some method. The closest I've
found is some documentation talking about some VME low level driver
http://www.n4comm.com/utogenf.htm I think that if I created some type of
driver that caught the file output and kept it in a buffer that might be
workable, but will take me some time to develop (havn't written any drivers
yet would take some reasearch).
>
If nothing is doable I'll wind up hacking all the source code to get it to
work throwing away large portions of graphviz in the process as what I
implement breaks other things I have no need for at this time, but may in
the future. I don't like changing library source code when I don't have to.

It seems you need Boost.Process, which is in limbo (not accepted).

For the stream redirection you might think about Boost.Iostreams , they seem to
fit the bill (hm, I did this in C in 1984 or so, all was much easier then! :-) ).

However, for the process handling it seems you'll have to use environment
specific means, or some library other than Boost.

Cheers, & hth.,

- Alf

stream -> iobuf*

stream -> iobuf*

Comment

Comment

Comment