Alf said:
* Jim Langston:
'iobuf' is not a standard type (i.e., it's environment-specific).
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:
ut'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.
