By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,305 Members | 1,614 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,305 IT Pros & Developers. It's quick & easy.

how to convert char* to File *

P: n/a
Hi,
I have a long string in char * and want to convert it to a File *
fp.
Is there any best way to do it without using tmpfile?

Thanks.

wy.

Jul 3 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a

cn**@263.net wrote:
Hi,
I have a long string in char * and want to convert it to a File *
fp.
Is there any best way to do it without using tmpfile?

Thanks.

wy.
Does this question make sense to anyone else? Are you trying to open a
file?

Jul 3 '06 #2

P: n/a
cn**@263.net wrote:
Hi,
I have a long string in char * and want to convert it to a File *
fp.
Is there any best way to do it without using tmpfile?

Thanks.
There is no standard way to slap a FILE* interface on top of an array.
(some systems provide an extension for that).
You can write the content of your array to a file and open that
though - as you hint you have discovered with your references to
'tmpfile'.

Then again it isn't that clear what you really need.
Jul 3 '06 #3

P: n/a
cn**@263.net writes:
Hi,
I have a long string in char * and want to convert it to a File *
fp.
Is there any best way to do it without using tmpfile?
I presume you mean FILE*, not File*.

What do you mean by "convert"? You can convert a char* to a FILE*
with a cast operator, but the result isn't going to be meaningful.
You can write a string to a file, but that's not what I'd call a
conversion. What exactly are you trying to accomplish?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 3 '06 #4

P: n/a

cn**@263.net wrote:
Hi,
I have a long string in char * and want to convert it to a File *
fp.
Is there any best way to do it without using tmpfile?

Thanks.

wy.
perhaps fmemopen(3) is you want.
please see
http://www.gnu.org/software/libc/man...g-Streams.html.

Jul 3 '06 #5

P: n/a
cn**@263.net writes:
Hi,
I have a long string in char * and want to convert it to a File *
fp.
Is there any best way to do it without using tmpfile?

Thanks.

wy.
I suspect you really want to know how to save and restore text to a
file? Your question doesnt really make sense so I have made a guess at
what you want based on it-

http://www.cprogramming.com/tutorial/cfileio.html
http://computer.howstuffworks.com/c18.htm

might help!

If it doesnt, then maybe you could explain why you need a File * and
what you intend it to be pointing at?

They assume you know some C : there are many books and tutorials
available. Use google.

Good luck!
Jul 3 '06 #6

P: n/a
cn**@263.net wrote:
Hi,
I have a long string in char * and want to convert it to a File * fp.
Is there any best way to do it without using tmpfile?
No, there's no portable way to do it without opening a file and writing
the string to it. OTOH, if you're not concerned about portability you
might consider the GNU C extension "phus" has mentioned in his reply to
you.

Jul 3 '06 #7

P: n/a

Sorry,I mean FILE *fp actrually.
There is a c function of a legacy system,which only accept FILE *fp
parameter and parse the content,and now the new system also provide
char* for the content,and I think saving char* to a file and opening it
to get FILE *fp then call the function is poor performance. so I doubt
is there any way to directly push char* into the stream without disk
reading and writing.

Jul 3 '06 #8

P: n/a
c...@263.net wrote:
Please quote the post to which you're replying since not all
participants of Usenet can as easily access previous posts as users of
Google Groups.
Sorry,I mean FILE *fp actrually.
There is a c function of a legacy system,which only accept FILE *fp
parameter and parse the content,
As far as I know, the FILE interface was standardised by ANSI. So your
"legacy" system must be an ancient UNIX implementation.
and now the new system also provide
char* for the content,
A char * is _very_ different from a FILE *. The latter is an
implementation specific abstract data type which is by necessity
associated with streams and is the only method to do I/O in standard C.
The former is simply a pointer to type char.
and I think saving char* to a file and opening it
to get FILE *fp then call the function is poor performance.
Why do you think so? Have you actually done measurements and concluded
that the speed requirements of your program are higher than what
standard C can offer. This is very rarely the case.
so I doubt
is there any way to directly push char* into the stream without disk
reading and writing.
Yes, if you want to convert data pointed to by a char *, to the FILE
interface, the only standard way is to open a FILE stream and to copy
data from your char array into it and fclose() or fflush() it. This
should be fast enough for most purposes.

Jul 3 '06 #9

P: n/a
cn**@263.net (in
11**********************@h44g2000cwa.googlegroups. com) said:

| Sorry,I mean FILE *fp actrually.
| There is a c function of a legacy system,which only accept FILE *fp
| parameter and parse the content,and now the new system also provide
| char* for the content,and I think saving char* to a file and
| opening it to get FILE *fp then call the function is poor
| performance. so I doubt is there any way to directly push char*
| into the stream without disk reading and writing.

If I'm understanding you correctly, you have something like:

int legacy_parse(FILE *fp)
{ char buffer[FILE_BUFFER_SIZE];

/* Get data from file into buffer */

/* Parse data in buffer */

return result;
}

....and you'd like to skip the step of writing the data to the file and
reading it back. It would seem that you could do that fairly easily by
simply passing the data that would have been read from the file to a
new version of the function that simply skips the file access, more or
less as follows:

int new_parse(char *buffer)
{
/* Parse data in buffer */

return result;
}

Where the /* Parse data in buffer */ logic remains unchanged. This is
probably (but not necessarily) an oversimplification - but it's up to
you to keep track of the details. :-)

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jul 3 '06 #10

P: n/a
Morris Dovey wrote:
cn**@263.net (in
11**********************@h44g2000cwa.googlegroups. com) said:

| Sorry,I mean FILE *fp actrually.
| There is a c function of a legacy system,which only accept FILE *fp
| parameter and parse the content,and now the new system also provide
| char* for the content,and I think saving char* to a file and
| opening it to get FILE *fp then call the function is poor
| performance. so I doubt is there any way to directly push char*
| into the stream without disk reading and writing.

If I'm understanding you correctly, you have something like:

int legacy_parse(FILE *fp)
{ char buffer[FILE_BUFFER_SIZE];

/* Get data from file into buffer */

/* Parse data in buffer */

return result;
}

...and you'd like to skip the step of writing the data to the file and
reading it back. It would seem that you could do that fairly easily by
simply passing the data that would have been read from the file to a
new version of the function that simply skips the file access, more or
less as follows:
Yes, the OP can do that unless the offending function is only available
in binary form.
The OP hasn't mentioned that yet.

Jul 3 '06 #11

P: n/a
santosh (in 11**********************@b68g2000cwa.googlegroups. com)
said:

| Morris Dovey wrote:
|| cn**@263.net (in
|| 11**********************@h44g2000cwa.googlegroups. com) said:
||
||| Sorry,I mean FILE *fp actrually.
||| There is a c function of a legacy system,which only accept FILE
||| *fp parameter and parse the content,and now the new system also
||| provide char* for the content,and I think saving char* to a file
||| and opening it to get FILE *fp then call the function is poor
||| performance. so I doubt is there any way to directly push char*
||| into the stream without disk reading and writing.
||
|| If I'm understanding you correctly, you have something like:
||
|| int legacy_parse(FILE *fp)
|| { char buffer[FILE_BUFFER_SIZE];
||
|| /* Get data from file into buffer */
||
|| /* Parse data in buffer */
||
|| return result;
|| }
||
|| ...and you'd like to skip the step of writing the data to the file
|| and reading it back. It would seem that you could do that fairly
|| easily by simply passing the data that would have been read from
|| the file to a new version of the function that simply skips the
|| file access, more or less as follows:
|
| Yes, the OP can do that unless the offending function is only
| available in binary form.
| The OP hasn't mentioned that yet.

Well, the OP did say that it was a _C_ function, and that its
parameters are known (and there hasn't yet been a request to
de-compile a binary. I'm being optimistic. :-)

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jul 3 '06 #12

P: n/a
Morris Dovey wrote:
cn**@263.net (in
11**********************@h44g2000cwa.googlegroups. com) said:

| Sorry,I mean FILE *fp actrually.
| There is a c function of a legacy system,which only accept FILE *fp
| parameter and parse the content,and now the new system also provide
| char* for the content,and I think saving char* to a file and
| opening it to get FILE *fp then call the function is poor
| performance. so I doubt is there any way to directly push char*
| into the stream without disk reading and writing.

If I'm understanding you correctly, you have something like:

int legacy_parse(FILE *fp)
{ char buffer[FILE_BUFFER_SIZE];

/* Get data from file into buffer */

/* Parse data in buffer */

return result;
}

...and you'd like to skip the step of writing the data to the file and
reading it back.
You don't know that the legacy parser reads all the data into a
buffer and then parses it. It might extract the data from the
input one token at a time, and never materialise the entire file
(indeed, this might be because files might be bigger than the available
memory).

I see three possibilities.

(a) The OP can change the legacy code. In which case, what I'd do
is replace /all/ the stuff taking FILE* with stuff taking
Stream [Stream* for those who prefer], where Stream is a
type with useful operations like read/write/close/etc and
which can be implemented with different tactics such as
read from a FILE* or read from a buffer or read from a
compressed Stream or read from a concatenation of Streams
or ... Then the existing uses become uses of a Stream over
a FILE* and the new use is a Stream over a buffer.

If something can't work this way, fall back to (b...).

(b) The OP can't change the legacy code, but will always be
running on a system which provides an implementation-specific
"fake FILE* reading from a buffer"; in which case, use
that.

(c) The OP can't change the legacy code and can't use a
implementation-specific hack, but write/read a file is
fast enough [MEASURE]: use write/read.

(d) None of the above: renegotiate.

--
Chris "I remember OSPub. I /used/ OSPub." Dollin
"No-one here is exactly what he appears." G'kar, /Babylon 5/

Jul 3 '06 #13

P: n/a

santosh 写道:
c...@263.net wrote:
Please quote the post to which you're replying since not all
participants of Usenet can as easily access previous posts as users of
Google Groups.
Sorry,I mean FILE *fp actrually.
There is a c function of a legacy system,which only accept FILE *fp
parameter and parse the content,

As far as I know, the FILE interface was standardised by ANSI. So your
"legacy" system must be an ancient UNIX implementation.
and now the new system also provide
char* for the content,

A char * is _very_ different from a FILE *. The latter is an
implementation specific abstract data type which is by necessity
associated with streams and is the only method to do I/O in standard C.
The former is simply a pointer to type char.
and I think saving char* to a file and opening it
to get FILE *fp then call the function is poor performance.

Why do you think so? Have you actually done measurements and concluded
that the speed requirements of your program are higher than what
standard C can offer. This is very rarely the case.
managment of the tempfile is another reason,
the c function will be linked into .so and be called by java using jni
in multi-thread envirnoment.the concurrent transaction will create a
lot of tmp file and may be the bottle for the whole system.
>
so I doubt
is there any way to directly push char* into the stream without disk
reading and writing.

Yes, if you want to convert data pointed to by a char *, to the FILE
interface, the only standard way is to open a FILE stream and to copy
data from your char array into it and fclose() or fflush() it. This
should be fast enough for most purposes.
any code snippets for it?of course I don't want to open a real file to
do it.

Thank you for your help.

Jul 3 '06 #14

P: n/a

Morris Dovey 写道:
cn**@263.net (in
11**********************@h44g2000cwa.googlegroups. com) said:

| Sorry,I mean FILE *fp actrually.
| There is a c function of a legacy system,which only accept FILE *fp
| parameter and parse the content,and now the new system also provide
| char* for the content,and I think saving char* to a file and
| opening it to get FILE *fp then call the function is poor
| performance. so I doubt is there any way to directly push char*
| into the stream without disk reading and writing.

If I'm understanding you correctly, you have something like:

int legacy_parse(FILE *fp)
{ char buffer[FILE_BUFFER_SIZE];

/* Get data from file into buffer */

/* Parse data in buffer */

return result;
}
it's something like:
FILE *fp;

fp = fopen(file, mode);
....
and a lot of fscanf to do parsing.

>
...and you'd like to skip the step of writing the data to the file and
reading it back. It would seem that you could do that fairly easily by
simply passing the data that would have been read from the file to a
new version of the function that simply skips the file access, more or
less as follows:

int new_parse(char *buffer)
{
/* Parse data in buffer */

return result;
}

Where the /* Parse data in buffer */ logic remains unchanged. This is
probably (but not necessarily) an oversimplification - but it's up to
you to keep track of the details. :-)

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jul 3 '06 #15

P: n/a
cn**@263.net wrote:
santosh 写道:
c...@263.net wrote:
.... snip ...
and I think saving char* to a file and opening it
to get FILE *fp then call the function is poor performance.
Why do you think so? Have you actually done measurements and concluded
that the speed requirements of your program are higher than what
standard C can offer. This is very rarely the case.

managment of the tempfile is another reason,
the c function will be linked into .so and be called by java using jni
in multi-thread envirnoment.the concurrent transaction will create a
lot of tmp file and may be the bottle for the whole system.
Well, read Chris Dollin's reply to Morris Dovey, but if the existing
method is _found_ to be too slow, (not just believed to be), the only
practical option you've got is to reimplement the legacy function to
accept char pointers. If the source is available, you might not have to
change too much.

Jul 3 '06 #16

P: n/a
cn**@263.net writes:
Sorry,I mean FILE *fp actrually.
There is a c function of a legacy system,which only accept FILE *fp
parameter and parse the content,and now the new system also provide
char* for the content,and I think saving char* to a file and opening it
to get FILE *fp then call the function is poor performance. so I doubt
is there any way to directly push char* into the stream without disk
reading and writing.
So you have a string, and you want to arrange for that string to be
read from a FILE*, but you're concerned that writing to and reading
from a disk file will be too slow.

There's nothing in the C standard that says a FILE* has to be
associated with a disk file. A file is just an external source of
data that can be opened given its name, and that behaves in certain
ways. The actual data can be stored on disk, in memory, or on clay
tablets as far as the C standard is concerned.

On some systems, you might have (or be able to create) a file or file
system that's actually stored in memory. <OT>It's not uncommon for
/tmp on Unix systems to be implemented with something called "swapfs";
see Google or your system's documentation for details.</OT>

Standard C provides the tmpfile() and tmpnam() functions. If your
system provides a file system that's not limited by disk speeds, it's
not unlikely that tmpfile() and tmpnam() will use it.

Implementations typically do buffering at various levels. If you
create a temporary file, write to it, use freopen() to re-open it in
input mode, you *might* be able to avoid writing the data to disk.
This is not guaranteed; in addition, C99 7.19.5.4, "The freopen
function", says

It is implementation-defined which changes of mode are permitted
(if any), and under what circumstances.

Your system might provide something that lets you associate a FILE*
with a string. Any such feature is, of course, non-portable.

<OT>
C++ provides something called "string-based streams", which act like
file streams but are associated with strings rather than external
files. If you have a C++ implementation, and if C++ provides a way to
associate a string-based stream with a C-style FILE* (I have no idea
whether it does), you might be able to interface with some C++ code to
do what you need. Obviously any questions about this approach (if
it's possible at all) belong in comp.lang.c++.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 3 '06 #17

P: n/a
On 3 Jul 2006 03:40:56 -0700, in comp.lang.c , cn**@263.net wrote:
>Hi,
I have a long string in char * and want to convert it to a File *
This doesn't make sense (at least, it makes as much sense as saying 'I
have a cow, I want to convert it to a Daschund').

What are you actually trying to do? That is to say, what is the
problem you are trying to solve?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 3 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.